T2D Alpha 3 Comments / Suggestions
by Matthew "Ashteth" Kee · in Torque Game Builder · 01/20/2006 (12:10 pm) · 10 replies
This ended up being kind of a long post and I don't want to monopolize the T2D Alpha 3 release announcement.
New releases are always appreciated. That said, I don't plan to heavily use this release or any new T2D release in the near future until the SDK has stabilized a bit more. I have a lot of custom code that I have added to the engine and I don't like having to reapply my changes once a month and changing all my datablock structures etc. I do appreciate everyone who actually is using these alpha releases and helping make the system more stable for when I do migrate.
I did examine the new code base. Here are my thoughts on the new release:
- It would be nice if we could get some ideas of what systems are relatively stable. In other words, what systems are unlikely to change significantly in the future. This would be especially useful for things like Datablocks. I.E. Have we finally settled on an image map datablock format or are we going to continue to make changes that will cause repercussions throughout my entire program? How about the tile map format? I realize that this is still an alpha, but could we please get an idea of what has stabilized?
- The packaging tool is nice. It would be better if it could package up / encrypt resources. I understand that there are addons that encrypt resources but a built in tool that did this as part of the packaging process would be extremely useful. I don't particularly care how strong the encryption is. A weak XOR encryption would suffice.
- Keep the string format arguments. While somewhat strange at first, the current string argument system I.E. setPosition("16 16") is superior to the new proposed system of setPosition(16, 16); The string system is superior because it allows the scriptor to store related coordinates in a single variable which in turn translates to fewer assignment statements and fewer variables. Deprecating the old system completely would cause my existing code base an awful lot of problems.
- I still want a t2dSceneObject::renderObject() function that takes a bounding rectangle as an argument and renders the scene object in this bounding rectangle. The addition of this function would allow us to do things like render T2D scene objects in the standard Torque GUI.
- Could we please get a flood fill tool for the tile map editor? I have begun to work on tile maps and the backgrounds are all filled with one tile. Currently I have to fill each grid square by hand with a single tile repeatedly. Its sort of annoying.
- Keep up the good work. Despite my somewhat cynical decision to avoid migrating to the latest alpha, I still like to see new releases and updates. Overall, I think the developers are doing a good job.
New releases are always appreciated. That said, I don't plan to heavily use this release or any new T2D release in the near future until the SDK has stabilized a bit more. I have a lot of custom code that I have added to the engine and I don't like having to reapply my changes once a month and changing all my datablock structures etc. I do appreciate everyone who actually is using these alpha releases and helping make the system more stable for when I do migrate.
I did examine the new code base. Here are my thoughts on the new release:
- It would be nice if we could get some ideas of what systems are relatively stable. In other words, what systems are unlikely to change significantly in the future. This would be especially useful for things like Datablocks. I.E. Have we finally settled on an image map datablock format or are we going to continue to make changes that will cause repercussions throughout my entire program? How about the tile map format? I realize that this is still an alpha, but could we please get an idea of what has stabilized?
- The packaging tool is nice. It would be better if it could package up / encrypt resources. I understand that there are addons that encrypt resources but a built in tool that did this as part of the packaging process would be extremely useful. I don't particularly care how strong the encryption is. A weak XOR encryption would suffice.
- Keep the string format arguments. While somewhat strange at first, the current string argument system I.E. setPosition("16 16") is superior to the new proposed system of setPosition(16, 16); The string system is superior because it allows the scriptor to store related coordinates in a single variable which in turn translates to fewer assignment statements and fewer variables. Deprecating the old system completely would cause my existing code base an awful lot of problems.
- I still want a t2dSceneObject::renderObject() function that takes a bounding rectangle as an argument and renders the scene object in this bounding rectangle. The addition of this function would allow us to do things like render T2D scene objects in the standard Torque GUI.
- Could we please get a flood fill tool for the tile map editor? I have begun to work on tile maps and the backgrounds are all filled with one tile. Currently I have to fill each grid square by hand with a single tile repeatedly. Its sort of annoying.
- Keep up the good work. Despite my somewhat cynical decision to avoid migrating to the latest alpha, I still like to see new releases and updates. Overall, I think the developers are doing a good job.
#2
01/21/2006 (1:08 pm)
I'd also like to see the package utility do some encryption. I'm no expert but I wonder how difficult it would be to hack that in. 
#3
keeping them lumped together in 1 argument of "16 16" is also supperior from a performance perspective.
In case people have forgot, torquescript is a run-time-parsed language. meaning that if you double the parameters passed to a function, you double the amount of look-up time for those parameters, which is NOT a cheap operation in torquescript (if you dont belive me, set a breakpoint on your favorite function and step through the parser operations)
01/21/2006 (3:40 pm)
Speaking of the string-arguments,keeping them lumped together in 1 argument of "16 16" is also supperior from a performance perspective.
In case people have forgot, torquescript is a run-time-parsed language. meaning that if you double the parameters passed to a function, you double the amount of look-up time for those parameters, which is NOT a cheap operation in torquescript (if you dont belive me, set a breakpoint on your favorite function and step through the parser operations)
#4
instead of
is worth keeping the "x y" way. If it doesn't lead to too much confusion, I would say, let the functions stay overloaded like they are now.
EDIT:
Some syntactic sugar for torque-script replacing the getWord() function would be nice. Something like
01/21/2006 (4:04 pm)
I think alone that you can do things like$x.setPosition( $y.getPosition() );
instead of
$x.setPosition( getWord( $y.getPosition(), 0), getWord( $y.getPosition(),1) );
is worth keeping the "x y" way. If it doesn't lead to too much confusion, I would say, let the functions stay overloaded like they are now.
EDIT:
Some syntactic sugar for torque-script replacing the getWord() function would be nice. Something like
%pos(0)instead of
getWord(%pos,0)would be really nice.
#5
Not quite true, although I can see how black-boxxing it would make you think.
TorqueScript is a byte-code compiled language. That's what the .dso's are--bytecode versions of the actual script you read as a human. Obviously you have to still parse the bytecodes and variable tokens, but it's not a strict "interpreted" language that is normally thought of when you say "run-time-parsed".
Not picking on ya Jason, it's just a sometimes misunderstood point, so I wanted to make it for future readers.
Disclaimer: I'm not an expert on Torque's bytecode FSM, so it's possible that some portions are still treated as strings instead of tokens within certain states, but at least a large majority of your script is converted to bytecode.
01/22/2006 (2:38 pm)
Quote:
In case people have forgot, torquescript is a run-time-parsed language
Not quite true, although I can see how black-boxxing it would make you think.
TorqueScript is a byte-code compiled language. That's what the .dso's are--bytecode versions of the actual script you read as a human. Obviously you have to still parse the bytecodes and variable tokens, but it's not a strict "interpreted" language that is normally thought of when you say "run-time-parsed".
Not picking on ya Jason, it's just a sometimes misunderstood point, so I wanted to make it for future readers.
Disclaimer: I'm not an expert on Torque's bytecode FSM, so it's possible that some portions are still treated as strings instead of tokens within certain states, but at least a large majority of your script is converted to bytecode.
#6
I'm not disputing the use of torquescript, as it very obviously does it's job well, but that's not really what i was getting at by my comment.
that's what i'm getting at. because if you step through, you will see that the parser code needs to loop through 4 or 5 more times (pushing/popping stuff to get the other variable) before passing the arguments to the actual function.
Granted, that additional work probably amounts to about 1/100th of a second (if even that) but considering how many of these function calls are made each world-tick, i see it as a potential perf leak, not giving much bang for the buck.
but hey, i'm not a torque or torquescript coder, so I really dont have any way of quantifying my statements. i just know for sure that you will be incurring extra loops through the parser... though that extra time may be 1/100th of a second, 1/1000th, or more, or less.
01/22/2006 (3:20 pm)
@Stephen, the byte-code dso's are still parsed at runtime, so while it's not parsing the human-code it is still reading the machine-equivlant of that. I'm not disputing the use of torquescript, as it very obviously does it's job well, but that's not really what i was getting at by my comment.
Quote:
keeping them lumped together in 1 argument of "16 16" is also supperior from a performance perspective.
that's what i'm getting at. because if you step through, you will see that the parser code needs to loop through 4 or 5 more times (pushing/popping stuff to get the other variable) before passing the arguments to the actual function.
Granted, that additional work probably amounts to about 1/100th of a second (if even that) but considering how many of these function calls are made each world-tick, i see it as a potential perf leak, not giving much bang for the buck.
but hey, i'm not a torque or torquescript coder, so I really dont have any way of quantifying my statements. i just know for sure that you will be incurring extra loops through the parser... though that extra time may be 1/100th of a second, 1/1000th, or more, or less.
#7
01/22/2006 (4:08 pm)
I honestly would prefer to have both, or just the string version of the functions. It would be nice to keep things consistent with TGE, rather than changing random things. Every variable is a string in TorqueScript. I don't know if performance is a big deal, because either way you are parsing two numbers from strings into numbers. If anything, the single string format is probably slower to parse, because it has to do an extra step to find the start of the next word. I really think consistency should be the determining factor when making changes. Another consideration would of course be how it could break existing code. Those are my thoughts on this issue.
#8
01/22/2006 (8:33 pm)
@Jason: aye, I wasn't disagreeing with you, just wanted to clarify for future readers was all. This point (what bytecode is, etc.) comes up relatively often!
#9
01/23/2006 (12:07 am)
TorqueScript is a bytecode, interpreted language, just like Java is. Some Java interpreters have JIT (just in time) compilers that turn the code into native machine code on the host machine. TorqueScript doesn't have this functionality, and I don't even think it would be a good idea, due to the dynamic nature of the language.
#10
01/23/2006 (12:21 am)
Well anyways I got slightly side tracked on the last post, but I just thought of something. You could implement both types of arguments in console commands, by just testing how many arguments are passed to the console command. So yes, it will require each function call to run the test, but on the other hand, it's a very quick test. Other than that test, the code could be identical, with no other of speed penalty. The parsing of the strings into numbers is so slow in comparison, that you probably wouldn't be able to notice a speed difference, even with a profiler. And of course, then everyone would be happy too. 
Torque Owner Jason Cahill
Default Studio Name
setPosition(string coords) { x = getWord(coords, 0); y = getWord(coords, 1); .setPosition(x, y); }If we had both, I would only ever use the distinct parameter version, but it would allow others with more code from 1.0.2 to reuse.