Swimmin' in the lab
by Gerald Fishel · 03/13/2009 (7:19 pm) · 7 comments
It's been a while since my last blog, and I've gotten a number of requests about what I've been working on. We're still not ready to show much but I figured I'd throw out a quick eye candy screenie. It's still a work in progress, but kinda neat nonetheless.
----
A quick mention for a couple of other projects I've got going on as well.
I'm about 80% done with an integration of Mono with TGEA 1.8.1. I'm just going through and implementing wrapper classes for all of the core object types right now. What this means is the ability to use .NET as a scripting platform for the core TGEA game engine. So we can use C#, IronPython and Javascript, just to name a few, for some serious rapid prototyping without the hideous performance of TorqueScript.
I've also been working on a new editor suite for TGEA. We've been using it in-hosue already, but I'm waiting for GGs announcement on their new tool sets for T3D so I can decide what I can make available without stepping on their toes.
More info to come soon.
Cheers
----
A quick mention for a couple of other projects I've got going on as well.
I'm about 80% done with an integration of Mono with TGEA 1.8.1. I'm just going through and implementing wrapper classes for all of the core object types right now. What this means is the ability to use .NET as a scripting platform for the core TGEA game engine. So we can use C#, IronPython and Javascript, just to name a few, for some serious rapid prototyping without the hideous performance of TorqueScript.
I've also been working on a new editor suite for TGEA. We've been using it in-hosue already, but I'm waiting for GGs announcement on their new tool sets for T3D so I can decide what I can make available without stepping on their toes.
More info to come soon.
Cheers
#2
03/13/2009 (10:25 pm)
No specific numbers off hand. The execution of the code itself is not bad, but it's all pass-by-value, so any kind of recursive algorithms working on arrays or something like that grinds things to a halt pretty quickly.
#3
on a simple for loop, where torqueScript was doing a few tens of thousand of iteration per seconds, another interpreted language (lingo from Adobe Director) was doing a few hundreds of thousand iteration.
On a quickSort on an array structure made in torqueScript, with scriptObjects, sorting 5000 objects took nearly 20 seconds. The same test done on a C++ array structure, it took a few miiliseconds.
Nicolas Buquet
www.buquet-net.com/cv/
03/14/2009 (2:44 am)
I made some tests 2 years ago :on a simple for loop, where torqueScript was doing a few tens of thousand of iteration per seconds, another interpreted language (lingo from Adobe Director) was doing a few hundreds of thousand iteration.
On a quickSort on an array structure made in torqueScript, with scriptObjects, sorting 5000 objects took nearly 20 seconds. The same test done on a C++ array structure, it took a few miiliseconds.
Nicolas Buquet
www.buquet-net.com/cv/
#4
03/14/2009 (2:46 am)
TS is not hideous or anything when it comes to performance, but it hasn't really had the extensive attention that some other modern script languages have been getting. especially if you've got a script engine with a JIT like actionScript or (i think) javascript, you can see some pretty blazing performance out of it. 
#5
@Gerald - is the water effect a shader on the tubes' material?
03/14/2009 (6:55 am)
Quote:The same test done on a C++ array structure, it took a few miilisecondsI guess that's why game engines come in code and not script.
@Gerald - is the water effect a shader on the tubes' material?
#6
TorqueScript is fine for doing simple things, but it quickly breaks down for doing anything fancy or advanced. And some things are nearly impossible. While doing things in C++ gives you full control, waiting for it to compile after each change gets annoying. Especially if you want to add a method to something that is referenced in a lot of places. The mono code still has to be compiled, but that takes less than a second in most cases.
With Mono I'm getting almost the same performance as with C++. And there are a few additional benefits.
For one it gives me access to just about any .NET assembly. One of the first things I did was implement an XML reader. So I can define lists of SimObjects in XML rather than as script. On the surface that doesn't seem like it makes much difference, but it makes visualization of the data nicer, plus makes writing tools for it easier. I could have just used TinyXml in C++, but it's a bit limited and doesn't support unicode. Implementing any of the other XML libraries is a chore because of some of the stuff done in the Torque code. In C# it took about 100 lines of code.
It also gives me compile-time type checking and error reporting, so I don't have to run the app, go through the motions, and read the log file to find out I've got a syntax error.
The one thing I can't do is execute arbitrary script code at runtime, in the console for example. I rarely do that anyway, but TS is still there and making the .NET code accessible from TS is pretty simple too.
03/14/2009 (8:58 am)
@Steve, it's a render-to-texture effect with a fresnel shader. You can't really tell from that screenshot, but there's 2 parts to it. 1 is the blue fresnel effect, and there's also a reflective glass effect on the outside.TorqueScript is fine for doing simple things, but it quickly breaks down for doing anything fancy or advanced. And some things are nearly impossible. While doing things in C++ gives you full control, waiting for it to compile after each change gets annoying. Especially if you want to add a method to something that is referenced in a lot of places. The mono code still has to be compiled, but that takes less than a second in most cases.
With Mono I'm getting almost the same performance as with C++. And there are a few additional benefits.
For one it gives me access to just about any .NET assembly. One of the first things I did was implement an XML reader. So I can define lists of SimObjects in XML rather than as script. On the surface that doesn't seem like it makes much difference, but it makes visualization of the data nicer, plus makes writing tools for it easier. I could have just used TinyXml in C++, but it's a bit limited and doesn't support unicode. Implementing any of the other XML libraries is a chore because of some of the stuff done in the Torque code. In C# it took about 100 lines of code.
It also gives me compile-time type checking and error reporting, so I don't have to run the app, go through the motions, and read the log file to find out I've got a syntax error.
The one thing I can't do is execute arbitrary script code at runtime, in the console for example. I rarely do that anyway, but TS is still there and making the .NET code accessible from TS is pretty simple too.
#7
The thing to consider about TS is that it's "typeless" and considers everything a string, string operations being more costly compared to arithmetic operations.
Still, I didn't gain nearly as many FPS back converting the main script function I was using to code (maybe 5FPS max at that point) as when I took out the error() and echo() functions from it. This was on TGEA 1.7.0.
03/14/2009 (12:24 pm)
@James: I was playing with some performance for AI once and noticed that removing echo()'s gave a huge increase in FPS (30FPS for the work performed by 100 NPC's compared to same amount when using the echo()'s for console spamming). This was after the error()'s were taken out previously, gaining 5FPS over the scripting which both echoed and reported errors to the console log.The thing to consider about TS is that it's "typeless" and considers everything a string, string operations being more costly compared to arithmetic operations.
Still, I didn't gain nearly as many FPS back converting the main script function I was using to code (maybe 5FPS max at that point) as when I took out the error() and echo() functions from it. This was on TGEA 1.7.0.
Torque Owner James Brad Barnette
3Dmotif LLC