Some questions about Torque 2d
by Michael Dowling · in Torque Game Builder · 03/06/2005 (2:24 pm) · 15 replies
I am interested in Torque 2d but I have never used Torquescript or TGE before, so I have some questions.
Are games programmed in Torque2d scripted using TorqueScript, or are they programmed in C++ and only use TorqueScript for scripting (the way people use LUA and other scripting languages)? If T2D is a scripted 2d engine, how can that be fast enough to compete with non-script based 2d engines/libs?
How fast is T2D? Can I have some benchmark results or something of blits/seconds, stretched blits/second, etc...?
All the features sound great, but is T2D actually capable of making more than just a space shooter? Can T2D load and play MP3s? Is there ever going to be support for drawing shapes and lines (I don't think that is incorporated yet)?
If I wait to buy T2D once it is more or less finished, are you guys going to raise the price?
Are games programmed in Torque2d scripted using TorqueScript, or are they programmed in C++ and only use TorqueScript for scripting (the way people use LUA and other scripting languages)? If T2D is a scripted 2d engine, how can that be fast enough to compete with non-script based 2d engines/libs?
How fast is T2D? Can I have some benchmark results or something of blits/seconds, stretched blits/second, etc...?
All the features sound great, but is T2D actually capable of making more than just a space shooter? Can T2D load and play MP3s? Is there ever going to be support for drawing shapes and lines (I don't think that is incorporated yet)?
If I wait to buy T2D once it is more or less finished, are you guys going to raise the price?
About the author
#2
1---
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.
03/06/2005 (2:38 pm)
I posted the following two posts in the private T2D thread in partial response to the same question about speed, but since there isn't anything proprietary at all about the answers, here they are again:1---
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.
#3
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.
Finally, when you purchase T2D, you have the source code. If you don't think TGEScript is fast enough for your particular game, then implement everything in C++!
03/06/2005 (2:39 pm)
And 2--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.
Finally, when you purchase T2D, you have the source code. If you don't think TGEScript is fast enough for your particular game, then implement everything in C++!
#4
When I said, "is it only capable of making spaceshooters", I mean can it handle a lot of graphical effects and other calculations simultaneously while still maintaining a decent FPS? For instance, the new 2Dish Zelda game on GameCube, with excellent code and implementation, is T2D hypothetically capable of something like that?
Also, about the shapes and lines, I thought the whole premise of T2D was fast and easy game development without having to worry about coding the engine yourself.
Is TGEscript wildly different from C++ code, or is it fairly similar? Newb question: Are there example scripts I could look at somewhere?
03/06/2005 (5:47 pm)
Thanks for the replies. I would probably have to test the thing out before I bought it-- that's just how I am. I thought I saw somewhere that a demo of the actual engine will be released in the future, and I'll be waiting for it. When I said, "is it only capable of making spaceshooters", I mean can it handle a lot of graphical effects and other calculations simultaneously while still maintaining a decent FPS? For instance, the new 2Dish Zelda game on GameCube, with excellent code and implementation, is T2D hypothetically capable of something like that?
Also, about the shapes and lines, I thought the whole premise of T2D was fast and easy game development without having to worry about coding the engine yourself.
Is TGEscript wildly different from C++ code, or is it fairly similar? Newb question: Are there example scripts I could look at somewhere?
#5
Considering there selling a source code version now and A compiled only version later, I can't see why or how they would go about releasing a demo that would allow you to do the same thing for free.
Unless, of course, they limit the usage.
I'm like you when it comes to testing things first. I dropped the money for the EA and I do not regret it at all.
If you want to get an idea of the scripts, look at some of the tutorials on the site for TGE or at the official docs.
I will say that T2D scripting is a lot easier to get your mind around though. It's just the same code, just easier to get a grip on
Here is a link to the docs
www.garagegames.com/docs/torque/
03/06/2005 (6:19 pm)
I don't know about there being a scriptable demo. If there is that would surprise me.Considering there selling a source code version now and A compiled only version later, I can't see why or how they would go about releasing a demo that would allow you to do the same thing for free.
Unless, of course, they limit the usage.
I'm like you when it comes to testing things first. I dropped the money for the EA and I do not regret it at all.
If you want to get an idea of the scripts, look at some of the tutorials on the site for TGE or at the official docs.
I will say that T2D scripting is a lot easier to get your mind around though. It's just the same code, just easier to get a grip on
Here is a link to the docs
www.garagegames.com/docs/torque/
#6
I guess most people's perspective is "why would you ever want to worry about drawing shapes and lines (manually)...".
T2D lets you manage tiles and sprites and image maps...with full collision and physics. Drawing lines is way lower level then you'll ever want to deal with using T2D...
For example, in less than a week, we already have:
Retro/remake of Atari "Combat".
A retro "Breakout".
An extremely high production (art) quality side scroller shooter.
Probably dozens of other style projects moving along just slightly slower (and not by much!).
Why in the world would you want to draw lines?
03/06/2005 (9:26 pm)
Quote:Also, about the shapes and lines, I thought the whole premise of T2D was fast and easy game development without having to worry about coding the engine yourself.
I guess most people's perspective is "why would you ever want to worry about drawing shapes and lines (manually)...".
T2D lets you manage tiles and sprites and image maps...with full collision and physics. Drawing lines is way lower level then you'll ever want to deal with using T2D...
For example, in less than a week, we already have:
Retro/remake of Atari "Combat".
A retro "Breakout".
An extremely high production (art) quality side scroller shooter.
Probably dozens of other style projects moving along just slightly slower (and not by much!).
Why in the world would you want to draw lines?
#7
The thing is called Torque 2D. Last time I checked lines, boxes, triangles, circles...all are 2D. These primitive drawing commands have been included in every graphic lib I have ever used.
I understand that it is an early release, and may be in the to-do list.
Why would drawing lines be way lower level than what I would want to do with T2D? Would it cause a tremendous performance hit or something?
03/06/2005 (11:35 pm)
What would it hurt to include primitive drawing functions? What if I wanted to render a table or a chart with cells and data in them (display scores, change options, etc..)? The thing is called Torque 2D. Last time I checked lines, boxes, triangles, circles...all are 2D. These primitive drawing commands have been included in every graphic lib I have ever used.
I understand that it is an early release, and may be in the to-do list.
Why would drawing lines be way lower level than what I would want to do with T2D? Would it cause a tremendous performance hit or something?
#8
We've written a checkers, side-scroller, pool, grav-gun (Half-Life#2 style), fish-tank and other demos to give people an idea of the kind of things you can write. You could use T2D to present stock market information if you so wished.
The T2D api is at a level which doesn't lend itself towards any particular application so you're free to use it for whatever you want.
What T2D isn't... We don't have the old-school concept of blitting. We utilised 3D hardware which gives us advantages such as hardware rotations, scaling, blending etc. We don't paint-pixels to the screen, we deal texturing primitives.
We've got a good rigid-body dynamics system and a very fast swept-polygon/polygon collision detection system. All of this stuff can be switched-on/off so you don't get hits.
I'd highly recommend reading a non-biased opinion of David "FenrirWolf" Grace in his recent plan. He is very experienced in writing 2D games and has done well to discuss both the good and bad points of T2D.
I would only add that if you are finally in any doubt that T2D isn't for you, don't purchase it. I wouldn't want you to spend your hard-earned money on something that you don't want no matter how powerful I thought T2D was.
- Melv.
03/07/2005 (12:38 am)
We will be including textured/non-textured primitives in T2D. It's not in there right now though because we're working on more critical aspects of T2D. T2D is script-driven but I'm a C++ guy through and through and I made sure that deriving your own custom stuff from T2D ones is real easy ... real easy. T2D is fast enough, full stop. I'm not playing the game of my app is faster than your app. T2D is a tool which can write practically any 2D game you care to imagine. T2D is not that slow that you'd be worrying whether to display 100 or 200 objects. We've written a checkers, side-scroller, pool, grav-gun (Half-Life#2 style), fish-tank and other demos to give people an idea of the kind of things you can write. You could use T2D to present stock market information if you so wished.
The T2D api is at a level which doesn't lend itself towards any particular application so you're free to use it for whatever you want.
What T2D isn't... We don't have the old-school concept of blitting. We utilised 3D hardware which gives us advantages such as hardware rotations, scaling, blending etc. We don't paint-pixels to the screen, we deal texturing primitives.
We've got a good rigid-body dynamics system and a very fast swept-polygon/polygon collision detection system. All of this stuff can be switched-on/off so you don't get hits.
I'd highly recommend reading a non-biased opinion of David "FenrirWolf" Grace in his recent plan. He is very experienced in writing 2D games and has done well to discuss both the good and bad points of T2D.
I would only add that if you are finally in any doubt that T2D isn't for you, don't purchase it. I wouldn't want you to spend your hard-earned money on something that you don't want no matter how powerful I thought T2D was.
- Melv.
#9
03/07/2005 (5:53 am)
I purchased Torque 2D but my mouse moves so slowly over the menu it is hard to work with. Any ideas?
#10
Could you provide a little more info so that we can help?
What OS? Computer? What's running when you're trying to do this? etc.
- Melv.
03/07/2005 (5:59 am)
@Colleen: You probably should post this as a seperate thread rather than tagging onto the end of this one as it can get missed easily. :)Could you provide a little more info so that we can help?
What OS? Computer? What's running when you're trying to do this? etc.
- Melv.
#11
Melv, what other additions can we expect put into the engine? Anything in the near future? Are there any price advantages to buying the engine now?
03/07/2005 (11:01 am)
I'm sure it is a brilliant engine. I have no doubt about that. I think I will wait for future releases to get more functionality, and because I don't have any money right now. I'm not at all looking to bash anybody or put down something. I just wanted some answers to questions I hadn't seen yet. Thanks for the anwers :)Melv, what other additions can we expect put into the engine? Anything in the near future? Are there any price advantages to buying the engine now?
#12
I don't know exactly when the prices will change and what they may be. This kind of thing happens when you 'place' the engine and is therefore relative to competition.
These are the things that you can expect over the coming year. No order, no promises although some will definately be happening.
- Focus on removing all known bugs.
- Distribution Tools.
- Refined image-handling code.
- Fully Networked Objects (not forced though).
- More sophisticated collision / physic code.
- More sophisticated tile-maps.
- Broader computer base.
- Animatable Properties.
- Professional Editor Packages / Smooth Workflow.
- Separate "Game Maker" Application.
- Complete Documentation / Tutorial Suite.
- 6+ Demos (at least) Should be a continuous one a month.
- C++ Customised Object Examples
- Pro Games being made.
- Pixel Shading.
- Thriving Community.
- NDA Stuff e.g. secret!
- Melv.
03/07/2005 (11:52 am)
@Michael: That's a shame really. Your game "Flatch" is the kind of fun games that I'd like to see. If you're at all unsure then it's best to hold off until you find out more.I don't know exactly when the prices will change and what they may be. This kind of thing happens when you 'place' the engine and is therefore relative to competition.
These are the things that you can expect over the coming year. No order, no promises although some will definately be happening.
- Focus on removing all known bugs.
- Distribution Tools.
- Refined image-handling code.
- Fully Networked Objects (not forced though).
- More sophisticated collision / physic code.
- More sophisticated tile-maps.
- Broader computer base.
- Animatable Properties.
- Professional Editor Packages / Smooth Workflow.
- Separate "Game Maker" Application.
- Complete Documentation / Tutorial Suite.
- 6+ Demos (at least) Should be a continuous one a month.
- C++ Customised Object Examples
- Pro Games being made.
- Pixel Shading.
- Thriving Community.
- NDA Stuff e.g. secret!
- Melv.
#14
Well, see, there's really no reason for lines, but think about an RTS.
I'd rather draw a rectangle than a sprite for the healthbar, and selection circles work better drawn, in my opinion.
Also, for choosing which way to face a formation...drawing sprites is an option, but maybe I'd rather use a line and circles.
03/14/2005 (2:00 pm)
"Why in the world would you want to draw lines?"Well, see, there's really no reason for lines, but think about an RTS.
I'd rather draw a rectangle than a sprite for the healthbar, and selection circles work better drawn, in my opinion.
Also, for choosing which way to face a formation...drawing sprites is an option, but maybe I'd rather use a line and circles.
#15
And they're easy to implement Ted, it's just that we've only got so much time. :)
You could knock together an object to draw primitive shapes in a couple of hours. Testing and documentation take much longer.
Seriously though, we'll do it, but we need to do a bunch of other stuff first.
Stuff like this is almost trivial to implement, it shouldn't stop anyone making games with T2D in the here and now.
- Melv.
03/14/2005 (2:43 pm)
Agreed, definately a good thing to have.And they're easy to implement Ted, it's just that we've only got so much time. :)
You could knock together an object to draw primitive shapes in a couple of hours. Testing and documentation take much longer.
Seriously though, we'll do it, but we need to do a bunch of other stuff first.
Stuff like this is almost trivial to implement, it shouldn't stop anyone making games with T2D in the here and now.
- Melv.
Associate Ian Omroth Hardingham
Mode 7 Games
Um... the things which take processing time are implemented in c++. But unless your USP is that you're throwing more sprites around than anyone else (and that would mean you'd have to beat Bangai-o, which would impress me), is that really what you care about? How about I tell you you can have 10000 sprites and if you need more you can go elsewhere.
I can think of about three ways of implementing a line drawing function, only one of which requires c changes, and none of which would take more than an hour. MP3 support is unlikely due to licensing issues, but OGG is a practical certainty (if it isn't in there already). Honestly though, "can it only make a space shooter?"? That's like being given a lego set which makes a castle and going "oh, I can only make a castle?!". You can make a whole lot more than that, as the attract videos show.
Ian