Does TextSprite support not latin text? I tried to make a symbol map with english and russian letters, english letters render well but russian letters are invisible

T2D calls GetVersionEx (or, rather, GetVersionExW) in a few places in an attempt to determine the Windows version and do various hacky things (like work around very old Voodoo & Windows 2000 bugs...).

Unfortunately this is wrong on two fronts. First, GetVersionEx has been deprecated since Windows 8.1 and will return the wrong version information depending on app compatibility settings, etc. More importantly, the workarounds used by the engine really shouldn't be necessary anymore, and seem like old left overs from the TGE codebase. In particular, the engine does things like disable DirectInput & delete the GL context on versions of Windows older than Win2k. Is anyone still releasing games that support Windows 98 and below?

In my opinion the correct way to go about this is to remove the calls to GetVersionEx altogether and do some cleanup on the winInput.cc and winOGLVideo.cc so the engine stops trying to support 20 year old operating systems. The other approach is to check for the Windows version the "correct" way, like so: http://stackoverflow.com/questions/22303824/warning-c4996-getversionexw-was-declared-deprecated

This branch allows Torque2D to be built for 64bit platforms, i.e. 64bit OSX and 64bit Windows.

The biggest change in this branch is in the TorqueScript compiler & interpreter. To allow for the fact that 64bit machines tend to use 64bit pointers, the code stream has been adjusted so that 8 bytes of data are reserved for string and namespace pointers instead of just 4.

For details, check out the post on GarageGames: http://www.garagegames.com/community/forums/viewthread/133068

The project files for Visual Studio 2010 and XCode have been modified to enable 64bit builds. Since I do not have a copy of Visual Studio 2012 installed, that project file remains unchanged.

This pull request includes the following changes:

• Addition of a 'Make' compiler folder, for use on Linux-like machines (BSD support has not been tested yet!)
  • Makefiles for Torque2D, zlib, lpng, ljpeg are all included.
• Rename 'box2d' folder to 'Box2D' to fix case sensitivity problems.
  • Includes changes to relevant project files for other platforms.
• Change a number of includes throughout the codebase to use proper case.
• Fix OpenAL searching and functionality for TORQUE_OS_LINUX
• Add necessary platform methods, some of which are currently stubs until SDL 2.0 is used.
• Fix platform main loop.
• Removed CD audio support since no other platforms support it anymore and it's basically irrelevant.
• Cleanup a few places with dead code.
• Get cpu frequency reporting to work correctly.

When working in the sandbox toys, or in modules of my own, collision normals appear to be getting inverted depending on the sequence of adding objects to a scene. Tested it through a variety of Torque development builds but the behavior has remained consistent and I have been unable to determine if it is something I am doing or not.

I create some basic platforms as such:

function PlatformerDemo::createPlatformBlock(%this, %posX, %posY, %sizeX, %sizeY)
{
    %posZ = 0;
    %object = SandboxScene.create( Sprite );
    %object.Size.x = %sizeX;
    %object.Size.y = %sizeY;
    %object.setBodyType("static"); // Platforms float, so we don't want them effected by gravity
    %object.Position = %posX SPC %posY SPC %posZ;
    %object.Image = "ToyAssets:Tiles";
    // Create some collision shapes.    
    %object.createPolygonBoxCollisionShape(%sizeX,%sizeY);
    %object.setSceneLayer(10);
    return %object;
}

When a player collides with the object, I check to see if its the top of a platform or block. If so, I turn off gravity on the player object and set a variable denoting that it is on the ground:

function Player::onCollision(%this, %colide, %details)
{
    %normal = getWord(%details, 2) SPC getWord(%details, 3);
    // Adjust our normal by rounding up a little
    %word0 = getWord(%normal, 0);
    %word1 = getWord(%normal, 1);
    %word0 = mFloatLength(%word0, 2);
    %word1 = mFloatLength(%word1, 2);
    %normal = mFloatLength(%word0, 4) SPC mFloatLength(%word1, 4);
    if (%normal $= "-0.0000 1.0000" || %normal $= "0.0000 1.0000")       // Haven't checked this recently, may be a result of my rounding, but sometimes the normal returns with a -0.0000 value on the first word so I try to account for both here
        {
        %this.onGround = true;
        %this.setGravityScale(0); // turn off gravity while we're grounded
        }
}

If the blocks are added to the scene before the player object, everything functions as expected. If the blocks are added after the player is added to the scene, those blocks act as if their normals were reversed: Landing on the top of the block keeps gravity on and treats the player like they are falling in the air. Touching the underside of the block, turns gravity off as if the player landed on the top of the block, and the player will be able to hang in the air and can run back and forth under the edge of the platform.

Currently I've worked around this by setting a flag on any blocks created when the player object already exists, and checking that flag on collisions. If its true, I reverse the normals before comparing them for the collisions.

When calling createPath, the path is not created. This occurs on all platforms.

the following code isn't working:

// When we create the toy, we want to check for a save file.
// set up our path and filename for save data.   
 PixelPainter.savedirectory = getUserDataDirectory() @ "/PixelPainter";

// if the save directory doesn't exist, create it.
 if (!isDirectory(PixelPainter.savedirectory))
 {
    createPath(PixelPainter.savedirectory);
 }

The isDirectory call returns false and the createPath call returns true, but the path is not created.

This was working as soon as a week ago when I implemented this script.

• Added Spine files
• Removed Leap Motion references
• Fixed multi-touch
• Case sensitivity fixes for Android on Linux (from camporter)
• Changes to work with latest NDK (from cam porter)

This replaces pull request #169

Since the 3.2 release, I can't get the engine to build on OSX. When compiling, it complains about needing libogg.dylib come link time, and when running a precompiled build, it crashes looking for libogg.dylib. I don't know the OSX build system well enough to fix it (yet, I'm tinkering with it now), but It sounds like we're not shipping the OSX version of certain OGG (and possibly vorbis) libs. Is this a boneheaded error on my part or do we have an issue here?

Updated code based on pull request #236 which uses the ContactFilter to avoid modifying the Box2D library. Currently chain and edge shapes need to be offset from the center of the scene object for the one way property to work. Thanks to @RichardRanft for the original submission.

Forum discussion can be found here: http://www.garagegames.com/community/forums/viewthread/138755

When opening the Solution file in Microsoft Visual C++ 2010 Express, the following error is generated

Solution folders are not supported in this version of the application. Solution folder 'Libraries' will be displayed as unavailable.

Once the error message is dismissed, the Output window displays the following message

Some of the properties associated with the solution could not be read.

Note that the solution still compiles without issues, in Debug, Release and Shipping build configurations.

There does not appear to be an option in the Express Edition to remove or manage Solution Folders.

Even removing the 'Libraries' folder from the Solution Explorer still generates the error.

Has anyone been able to compile an Android .apk with the recent version of the Development branch? I spent some time, will probably spend some more but haven't been able to resolve some of the errors I'm getting in android studio. I'm happy to share the specific problems, but wanted to know if there is a change in the build process that maybe hasn't been updated?

I was still following the Android Development Guide