Compared to other embeddable scripting languages, TorqueScript on average is quite slow. Anyone who has used TorqueScript heavily in an iTorque project has probably realized this. Mobile devices are of course slow, but it seems to me even doing simple things in TorqueScript is costly.

After actually benchmarking a rather simple function call ( https://gist.github.com/3737516 ), I was shocked after seeing just how bad it can get.

I'm not quite sure what the best way of tackling this is, so I'll provide as much information as I can in this Issue.

My tests seem to indicate that function calls in TorqueScript appear to be quite expensive, whereas in other embeddable scripting languages this is far from the case. Variable lookups also appear to be costly though this is true of any scripting language.

For reference, I tested 6 methods of adding two numbers together:

• scriptTest1 returns p1 + p2
• scriptTest2 sets global variable $_R to $_0 + $_1
• scriptTest3 is the same as scriptTest2 except it copies the global to local variables (similar performance to test 1)
• scriptTest4 is the same as scriptTest1, except the addition is done in C (ends up being faster)
• scriptTest5 is the same as scriptTest2, except the addition is done in C (and is actually slower)
• scriptTest6 adds two literals with no function calls, and is the fastest

I've placed the specific code I used for benchmarking TorqueScript, Ruby and Lua in a gist: https://gist.github.com/3760645 . All results are in milliseconds, the last number being the average time taken.

Torquescript results (Macbook Pro 2010 2.4ghz):

Torque3D RELEASE
scriptTest1,2220,2196,2224,2248,2632,2304
scriptTest2,692,688,696,692,692,692
scriptTest3,2224,2208,2236,2220,2208,2219.2
scriptTest4,448,436,436,432,432,436.8
scriptTest5,964,956,960,960,976,963.2
scriptTest6,280,288,284,280,288,284

The worst case here is 2.3s in the pure script function call. It seems making a local variable is costly as test 3 is the second worst case. Test 5 is oddly slower than test 2, and would be even slower if I used the actual Con:: getIntVariable function which does an int->string->int conversion.

The best case is 0.29s, which beats mruby but not lua.

mruby results for tests 1,2,3,6 (latest version, Macbook Pro 2010 2.4ghz):

TEST,1,2,3,4,5,AVG
scriptTest1,642.965,616.527,607.443,604.453,607.673,615.8122
scriptTest2,717.744,717.211,716.863,726.13,714.424,718.4744
scriptTest3,729.728,726.318,722.327,728.388,722.21,725.7942
scriptTest6,490.863,481.995,495.214,484.136,481.721,486.7858

Note that the worst case here is 0.73s.

Lua results for tests 1,2,3,6 (v5.2.1, Macbook Pro 2010 2.4ghz):

TEST,1,2,3,4,5,AVG
scriptTest1,177.313000,173.866000,173.777000,173.635000,172.777000,174.273600
scriptTest2,365.673000,366.093000,366.950000,367.679000,373.810000,368.041000
scriptTest3,495.440000,493.399000,490.451000,492.778000,491.064000,492.626400
scriptTest6,151.421000,150.907000,150.767000,149.743000,151.732000,150.914000

Note that the worst case here is 0.49s.

While working with the terrain blending, I found some artifacts when having more than 2 textures blended together. Steve_Yorkshire in IRC confirmed that he had also seen the issue, so I dug into it and found that the textures aren't blended properly. This PR fixes specifically the blending between the 2nd and the third texture.

Image of the issue here:

With this PR it looks like this:

Drastically improved the maintainability of the console API stuff. There are still two places with hardcoded array sizes preventing functions and methods of arbitrary arity from being exposed to the console, but code bloat has also been significantly reduced.

My understanding is that currently the Toolbox is written for an older version of QT that is not MIT compatible and that it's going to be updated for the latest versions of QT.

While I'm not normally for rewriting code bases from scratch, is there any particular arguments against rewriting it in Python with wxWidgets?

Reasons for:

• I can write it in an evening or a weekend (And I would volunteer to write it).
• You'll gain immediate cross platform compatibility without needing to recompile for every platform, or having three separate binaries for the three OS's.
• Changes and iterations can be fairly rapid.
• OS X comes by default with both Python and wxWidgets installed and ready for use.
• Linux usually comes with Python installed and wxWidgets is either already installed, or trivially installed.
• Faster iteration allows for things like proposed changes in Issue #15 to be added quickly and easily.

Reasons against:

• This would add both the Python and wxWidgets dependencies to the project or we'd have to require users to have downloaded it. This is pretty common practice, but I can certainly understand the objection. We do have the option of using something like Py2Exe, but that would be creating a special binary for windows.
• It would be a full rewrite. But again, it's simple enough that I could write it in a day or two.

Thoughts?

I've got Torque 3D MIT (dedicated build only) running on Linux box (OpenSUSE 12.1 x64). Also, got successfully connected from Windows 7 build (based on same sources) via LAN.

This doesn't change any functionality, so everything will work the same way as a stock version.

Build instructions (assuming my changes are applied to the code base):

cd Templates/Full
./generateProjects.command
cd buildFiles/Make_Ded
make clean
make debug
cd ../../game
./Full_DEBUG -dedicated -mission levels/myCustomLevel.mis

Keep in mind, that mission files should not contain spaces in its name. Also, if you make custom/own projects, I would recommend to store it under Torque3D/Projects folder instead of Torque3D/My Projects so it doesn't contain spaces in folder name. It will save you a lot of headaches.

Refactors console execution in order to resolve issue #1134. It does this by changing executef calls to templates which internally manage the stack, similar to how most modern C++ script binding libraries work. The templates also automatically perform type conversion, meaning you don't even need to bother converting your parameters to TorqueScript types - this is all done for you.

Along with this, all public execution calls (such as execute* and evaluate_) now save and restore the stack upon returning. They are also now thread safe, meaning they can be called from other threads (as long as get_Arg functions aren't used).

I've also added some basic tests for the core marshalling functionality in addition to the execution calls. This should hopefully trap any expected future regressions with this functionality.

In addition some callbacks have been corrected to use the correct types instead of strings which was causing a few problems.

This allows Torque3D to run on the open source Linux 3D drivers. There are still many issues but with this small patch it at least starts and is semi-functional.

• Explicitly request a GL 3.2 context
• Enable 'experimental' extensions on glew (This appears necessary to get glew to work with explictly set GL versions)

When trying to compile the development branch on Fedora 21 (x86_64) I ran into the following error:

• fatal error: SDL.h: No such file or directory

This micro contribution fixes the the SDL related header includes, so that the previously mentioned fatal error is resolved. This way the inclusion of SDL related headers is consistent with the the includes of these headers in other classes of this directory as well.

This PR adds an implementation of Tim Newell's ribbon code, with a "ParticleEmitterNode-like" RibbonNode.

Since receiveing the code from Tim, the following changes has been made:

• Option for fixed texCoords has been added to prevent "floating" textures.
• Tilescale has been added to scale texCoords.
• Now uses RIBBON_NUM_FIELDS instead of constant values for key value arrays.
• Option for skipping an amount of emitted segments such that you can optimize the ribbons when necessary by emitting e.g. 50% of the original amount of segments, at the cost of less "smoothness".
• Now only update buffers when new segments are added (Optimization).
• Option for preventing texture stretching, such that textures always look uniformly sized.
• A number of fixes, like being able to have more than 2 key-values.

This video shows off most of the new "front-end" features.

Update to make platform/types.h basic types F32, F64 S32, U32, etc consistent in the engine. This is also in reference to issue #85. I'm aware this may be one of the last merged, if at all.

Hi I just download the new version of torque3d I can't compile the damn thing hahaha

1>C:/Game Develop/Game Engine/T3D/Engine/source/gfx/gl/tGL/tGL.h(26): fatal error C1083: Cannot open include file: 'epoxy/gl.h': No such file or directory

I'm bit lose right now with all the changes but in the commit change I notice this "Merge pull request #1567: Added Epoxy in favor of GLEW" may be something was missing.

Sorry to ask this, out of nowhere, but we all can see that there's no active development for long time and that makes me suspect that the project has been abandoned.

I want to give TGE a try, but things are kinda awkward.

A piece of (probably normally unreachable code) was triggering a fatal error when run with PHP 7.0+, probably because of the optimizer checking it before execution. There was simply a continue statement that was not in the scope of a loop or switch statement. The only effect this really has is with fixing generating projects on linux/mac with a newer version of PHP on the system.

SDL 2.0.10 includes a bug that prevents SDL being built when the calling project is built in-tree, due to its' use of the global variables as opposed to the local variables when checking its requirement to be built out of tree.

This is on Windows, although something similar may happen on Mac and Linux. May also affect the mission editor (I haven't tried that yet).

If you attempt to save a GUI to a location outside of the main program directory the engine will crash and point to Stream::_write() with a 'Read Access Violation: this was nullptr' error. This occurs because the FileObject used in GuiEditCanvas::save() fails to open the location for writing (unless you're running the program as an admin/have elevated permissions) and the save() method doesn't check its return value to make sure it can actually write the data.

I've patched this in my repo by simply checking the return val & exiting the save() method early if it's false (around line 439 in guiEditorCanvas.ed.cs):

if(!%fo.openForWrite(%filename))
{
    error("GuiEditCanvas::save() - Unable to save, file location not open for writing.");
    %fo.close();
         
    return false;
}