General Torque Script Question

#1 1 - I don't know. I use "printf debugging" -- in other words echo("hello, world"); throughout my code to find logic errors. Torque does a fine job of catching your syntax errors.

2 - Other than that book (which I have too and is good), read through the tutorial doc and look at all of the sample code in the example folder. That helps figure a few things out.

3 - fast enough. The bulk of what you do in script are high-level create & control logic. That is almost never the performance bottle neck in a game. Torque takes care of all the low-level details for how it renders, processes platform events, etc, and that's the main place you get the big bottlenecks.

4 - Torque includes a script compiler. The code is JITed (just-in-time compiled) so whenever you load a file that is new or changed, Torque will recompile it into a .cs.dso (the dso is Dynamix Script Object I think? aka compiled code). The code is not machine language. I believe it is a higher-level IL (intermediate language) that they interpret in real time. Plenty fast enough. That's roughly how MS's .net and Java languages work too.

#2 @Jason - very cool! thanks for the input!

#3 Actually, IIRC, TGEScript is byte-code compiled at startup, instead of "Just in Time". That's why you can see script errors immediately after entering the game (via console), instead of only after you attempt to use a particular scripted funtionality. It's also not really "interpreted" in an absolute sense but is in fact compiled--it's just that compilation isn't a seperate process.

There is a historical community belief (and I mean programmers in general, not just GG community) that script languages are inherently much slower than compiled languages, but that really isn't the case--hasn't been since back in the 80's/90's when byte code compilation become the standard. For example, I use TCL (another byte-code compiled "script" language) to handle real time data manipulation for hospitals--all the data you put on to an admitting form for example when you show up at a hospital goes into a computer, and is then massaged, mapped, and otherwise modified to fit into dozens of other applications. I also know of actual oil well rigs that use TCL to handle all of the real time systems monitoring and management for at-sea oil rigs. Obviously, that couldn't work if scripted applications were particularly slow!

TGEScript has a pretty fast execution speed overall. It will never be as fast as a C++ version of an implementation, but that's not because it can't be--only because the time and resources required to make the TGEScript environment completely optimized for speed wouldn't be worth the last little bit of performance that might be squeezed out.

#4 I guess I'm just concerned that I'll be able to pull off real-time path finding and fairly complex logic very quickly while maintaining a good frame rate.

#5 I intend to develop almost a template object that shows how to implement your own clear object in T2D as well as inheriting from the core to give yourself physics etc. It's actually very simple to do, you'd be suprised.

I want to show how to put in functions and reference T2D objects in C++ so that you could create things like A* algos etc.

- Melv.

#6 Having the C++ source really makes most SCRIPT vs C++ SPEED arguements pointless.. If the script code is costing too much in cycle time. Rewrite it in C++ :)

#7 Good questions and answers, thanks guys. Here are my replies:

1 - Is there any way to set up break points for debugging? Is the console the primary debugger?
Not directly, though we do want to have a full-on script editor one day (not very soon, unfortunately, lots of other stuff to tackle).

You can use telnet debugging and use other debuggers though. For instance "Tribal IDE" can do this. This is a complicated matter though, and unfortunately I don't have time to look into it in more detail atm. You can search our resources here on the site though for more information.

2 - Where can I find a reference or tutorials on programming with torque script? I've got the 3d all in one book and that's a good start but more would be nice.
Ken Finney's book is great, and there's lots and lots more documentation here. See the official scripting docs the Essential Guide to Torque (you can skip to the scripting chapter for T2D, and lots of others! Joel Baxter's quick language reference is great. Ron Yacketta made a thorough study of the built-in TorqueScript functions[/url] some time ago and it's still very nice.

One nice thing about T2D is that it gets to inherit and leverage all the great work that has gone into documenting TGE over the past few years. :)

3 - I'm new to using scripting languages so I was wondering how fast torque script really is... this is more or less something I can experiment with I suppose...

It is quite fast, take it from me. :)

4 - How is the code compiled? I use Director a lot and it's programming language Lingo is run-time compiled so it's considered an interpreted language. Torque script is similar yes?
Stephen answered this question quite well.

#8 Thanks for the reply's guys. I've got other questions for sure so I'll pester you more later. Thanks again!

#9 Just to carry on a bit more about the difference between "interpreted" and "byte-code compiled".

Things are always going to be fuzzy because every application/language is going to do things slightly differently, but in general (and please, any purists out there--this is a layman's view of a layman's answer!):

A compiler takes text files and converts them into .obj files as an intermediate step, and then a linker ties all of these .obj files (and their internal forms of your text written code) into an executable application. The act of compiling to .obj files is a reduction from the human-readable language to a lower level, more efficient "machine processable" format. The level of reduction is compiler dependent, but we're not talking all the way down to assembler/machine language all of the time (note: this may not be true any longer--in fact, I may be wrong and compilers do actually produce machine code--it's been a while since my compiler theory days). The conversion from the high level language to the lower level language is basically on a "per primitive" level--the parser recognizes code structures, and basically replaces them with the lower level language versions during the compilation process.

An interpreter reads in the text formatter code character by character every time you execute a code section, even if you've already executed that code section during this application run. The interpreter pattern matches (normally with a finite state machine, although that's just one implementation) the tokens that are built character by character, and once it forms a valid token (including parameters, variables, etc.) it jumps off to carry out what the token requires, and then goes back to parsing character by character.

A byte-code compiler does a pre-parse of the script language (during the initial loading of the text file), and converts the text into a lower level representation of the code you've written (just like the compiler does), but doesn't necessarily carry it all the way down to the low level language that a compiler might. Once your code execution begins, a byte-code compiled language never actually refers to the text source again, but uses this much more highly optimized "byte-code" representation of your source code. That means that at execution time, it is much faster than a fully interpreted language, since it doesn't have to parse like an interpreter does each time a block is executed. However, since the byte-code representation most of the time isn't as "low level" as what a compiler would produce, it's not quite as fast...just much faster than interpreted languages.

#10 TorqueScript is fairly efficient... have been quite impressed... when running a database developed completely of Torquescript I was able to enter 1,000 simultaneous entries without a single delay... I hit some delay on 100,000, though it still was able to do it... though this was all at once... after entering the data nothing seemed to slow down... and I can't even imagine entering 1,000 entries at once...
if you underestimate script you cripple yourself... it has some very nice advantages of being typless :)

#11 Stephen: Thanks for that explanation! I had wondered about the differences. This kind of feedback is worth the $100 price tag alone... ;)