XNA and Torque Script
by The Collector · in Torque Game Engine · 09/04/2006 (1:20 pm) · 18 replies
I'm trying to figure out if I should resurrect my TorqueScript knowledge (e.g., by buying the second Torque book) based on the upcoming TorqueX engine.
Two questions:
* (the biggee) so the scripting language will basically be C#? If I'm reading the blogs/forums, etc. right, then TorqueScript has essentially morphed into the process of using C# to talk to a set of TorqueX GameComponents (in the XNA sense). I'm reading between a lot of lines with that statement, but is that correct?
* The 3d part of TorqueX is in planning/dev stage, right? So probably won't be avail. for several months (or sooner, not making judgements here :) even if beta started tomorrow? I couldn't tell if the marble blast demo stuff was from TorqueX or just showing the capabilities of Torque which was on the 360 already. I know the TorqueX product page says you can transfer TGB projects over, but I'm more interested in the 3d stuff.
Any help appreciated :{)}
Two questions:
* (the biggee) so the scripting language will basically be C#? If I'm reading the blogs/forums, etc. right, then TorqueScript has essentially morphed into the process of using C# to talk to a set of TorqueX GameComponents (in the XNA sense). I'm reading between a lot of lines with that statement, but is that correct?
* The 3d part of TorqueX is in planning/dev stage, right? So probably won't be avail. for several months (or sooner, not making judgements here :) even if beta started tomorrow? I couldn't tell if the marble blast demo stuff was from TorqueX or just showing the capabilities of Torque which was on the 360 already. I know the TorqueX product page says you can transfer TGB projects over, but I'm more interested in the 3d stuff.
Any help appreciated :{)}
#2
It's a good sign if they had marble blast 3d running with xna/c#. I would assume that means the libraries are at least somewhat mature then.
09/05/2006 (9:27 am)
Thanks Anton, Looks like my hunch was right about the scripting (or not scripting) part.It's a good sign if they had marble blast 3d running with xna/c#. I would assume that means the libraries are at least somewhat mature then.
#3
The Marble Blast demo was running in C# using TorqueX.
Initially you'll use C# to script TorqueX. We're considering the possibility of a cross platform language to control both C++ and C#.
In general, your C++ Torque knowledge is probably useful but hardly necessary to use TorqueX. It's a reimplementation of similar functionality, not a straight port.
09/16/2006 (9:44 pm)
We're focusing on the 2d stuff first.The Marble Blast demo was running in C# using TorqueX.
Initially you'll use C# to script TorqueX. We're considering the possibility of a cross platform language to control both C++ and C#.
In general, your C++ Torque knowledge is probably useful but hardly necessary to use TorqueX. It's a reimplementation of similar functionality, not a straight port.
#4
That sounds interesting. Can you elaborate on this a bit? I've never used C# before but from what I read about it I might prefer it to Torquescript. TS is a nice language but I'd feel better with a full blown object-oriented language. C# might be the golden middle between TS and C++.
09/17/2006 (2:23 am)
Quote:
Initially you'll use C# to script TorqueX. We're considering the possibility of a cross platform language to control both C++ and C#.
That sounds interesting. Can you elaborate on this a bit? I've never used C# before but from what I read about it I might prefer it to Torquescript. TS is a nice language but I'd feel better with a full blown object-oriented language. C# might be the golden middle between TS and C++.
#5
Some blanket statements:
1. You'll aways be free to use C# to control our XNA technology, of course, but we probably aren't going to adopt it as our core scripting language.
2. We're not looking to change our scripting language in the near or mid term, and even if we do eventually change away from it, TorqueScript will be supported as a legacy option for quite a while before it's retired for good... if ever. So I don't want to see anyone freaking out. ;)
3. Ultimately, it would awesome to be able to export a game, with scripts, from TGB to the 360/XNA stuff. But you're probably not gonna see it in the initial release. :)
09/17/2006 (2:43 am)
Not really - it's too far out to have a meaningful discussion about at this point.Some blanket statements:
1. You'll aways be free to use C# to control our XNA technology, of course, but we probably aren't going to adopt it as our core scripting language.
2. We're not looking to change our scripting language in the near or mid term, and even if we do eventually change away from it, TorqueScript will be supported as a legacy option for quite a while before it's retired for good... if ever. So I don't want to see anyone freaking out. ;)
3. Ultimately, it would awesome to be able to export a game, with scripts, from TGB to the 360/XNA stuff. But you're probably not gonna see it in the initial release. :)
#6
I want to start an XNA project but I'm not sure whether to start from scratch, wait for TorqueX or possibly develop in TSE and then see about porting from there if it were to be successful.
Certainly if TorqueX is going to be 2D TGB style to start with then that option's out the window for me ;)
09/17/2006 (2:58 am)
It's more of a TGB for XNA than a TGE/TSE then?I want to start an XNA project but I'm not sure whether to start from scratch, wait for TorqueX or possibly develop in TSE and then see about porting from there if it were to be successful.
Certainly if TorqueX is going to be 2D TGB style to start with then that option's out the window for me ;)
#7
09/17/2006 (3:00 am)
I'll have to let one of the XNA team members field that one, Ian. :)
#8
09/17/2006 (3:19 am)
Thanks Ben!
#9
C# is easier to read than C++ anyway, and if anyone disagrees with that I would say they dont know c++ and c# on an equal level.
09/17/2006 (3:55 am)
Ian, it wouldnt hurt to to start learning how to use XNA (and learn c# if you don't know it). That when, when torqueX is released you will be able to understand iit, and modify it. If it is freindlier now, which I'm sure it will be because its not mostly a 'reshaped' engine like TGE.C# is easier to read than C++ anyway, and if anyone disagrees with that I would say they dont know c++ and c# on an equal level.
#10
Holes in XNA (as a game platform -- it's fine as a basic rendering and input/output API):
1) No animation support (not even the DirectX animation track support).
2) No collision suport.
3) No physics support.
4) No networking support.
What's so annoying about it, is that they don't allow unsafe code, so you can't P/Invoke existing solutions or libraries for these missing pieces. You have to code them all from scratch in C#. Ick!
09/17/2006 (10:25 am)
XNA has some big holes. I was hoping TorqueX would focus on filling those, but it doesn't sound as if that will happen anytime soon.Holes in XNA (as a game platform -- it's fine as a basic rendering and input/output API):
1) No animation support (not even the DirectX animation track support).
2) No collision suport.
3) No physics support.
4) No networking support.
What's so annoying about it, is that they don't allow unsafe code, so you can't P/Invoke existing solutions or libraries for these missing pieces. You have to code them all from scratch in C#. Ick!
#11
That is to say - it's enough to build a fun game in. If you just have to have eighty thousand boxes bouncing around and fracturing dynamically before your game can be fun, then you'll have to wait for Havok or something to come over. :)
09/17/2006 (11:54 am)
The 3d stuff we already have (which runs MBU) already does all of those things, except networking - and I'm sure that we'll see TNL come over to C# eventually.That is to say - it's enough to build a fun game in. If you just have to have eighty thousand boxes bouncing around and fracturing dynamically before your game can be fun, then you'll have to wait for Havok or something to come over. :)
#12
However, the XNA team has said that networking is an XNA hole they want to fill.
09/17/2006 (2:38 pm)
As Ben said, the purpose of TorqueX is to provide all the engine-type functionality that XNA doesn't--all of the things in JW's list, except for networking--which XNA doesn't even currently provide a framework for.However, the XNA team has said that networking is an XNA hole they want to fill.
#13
09/17/2006 (2:42 pm)
Stephen's right - no bringing networking over until they give us a UDP send function. :)
#14
5) No scene graph.
But then, TGE doesn't have that, either.
Does TSE? Does TorqueX? Is there a software map somewhere that tells me what I'd get if I bought these different things?
09/17/2006 (3:22 pm)
I forgot:5) No scene graph.
But then, TGE doesn't have that, either.
Does TSE? Does TorqueX? Is there a software map somewhere that tells me what I'd get if I bought these different things?
#15
What are you looking for in a scenegraph? Check out Tom Forsyth's article on them at home.comcast.net/~tom_forsyth/blog.wiki.html.
I'm sure we'll have a full marketing/explanatory roll out once there's an actual product for you to buy. Until then it's kind of moot, I think... :)
09/17/2006 (3:24 pm)
Sure TGE does - how do you think it renders stuff? The 3d stuff in TorqueX is of course more refined, as is what's in TSE.What are you looking for in a scenegraph? Check out Tom Forsyth's article on them at home.comcast.net/~tom_forsyth/blog.wiki.html.
I'm sure we'll have a full marketing/explanatory roll out once there's an actual product for you to buy. Until then it's kind of moot, I think... :)
#16
We probably mean different things by "scene graph" -- for example, I believe that, if a content object calls glPushMatrix() and glBindTexture(), then you don't actually have a full implementation of a scene graph. I call that "immediate mode drawing" (which is separate from the GL kind of immediate mode).
In a scene graph (the way I define it), all rendering state is kept outside of the object, and the object detects state changes and updates the scene graph to represent the new changed state. Thus, if a ShapeBase was standing still, it wouldn't call into the scene graph at all, until it started moving, or somehow changed state so it had to update the data used to display it in the world.
The way I see it, TGE has a rendering utility library, not a scene graph. Note that a scene graph doesn't necessarily need to be API agnostic -- if the scene graph identifies textures by GL ids, for example, you could have a GL-specific scene graph, that still kept state outside of the object. Although it's easier to implement API agnosticism once you have a proper scene graph implementation.
Oh, and another thing: some people believe a scene graph needs to support inheritance of various attributes like rendering state (i e, I should by default be bark-textured and fogged just because my parent is) -- I don't see that particular behavior as a requirement rather than as a problem :-)
So, the question remains: how can I tell what I would be getting if I bought TSE? Is the API documentation online? (Of course, it might be as sparsely filled out as the TGE documentation...)
09/17/2006 (7:02 pm)
Quote:Sure TGE does - how do you think it renders stuff?
We probably mean different things by "scene graph" -- for example, I believe that, if a content object calls glPushMatrix() and glBindTexture(), then you don't actually have a full implementation of a scene graph. I call that "immediate mode drawing" (which is separate from the GL kind of immediate mode).
In a scene graph (the way I define it), all rendering state is kept outside of the object, and the object detects state changes and updates the scene graph to represent the new changed state. Thus, if a ShapeBase was standing still, it wouldn't call into the scene graph at all, until it started moving, or somehow changed state so it had to update the data used to display it in the world.
The way I see it, TGE has a rendering utility library, not a scene graph. Note that a scene graph doesn't necessarily need to be API agnostic -- if the scene graph identifies textures by GL ids, for example, you could have a GL-specific scene graph, that still kept state outside of the object. Although it's easier to implement API agnosticism once you have a proper scene graph implementation.
Oh, and another thing: some people believe a scene graph needs to support inheritance of various attributes like rendering state (i e, I should by default be bark-textured and fogged just because my parent is) -- I don't see that particular behavior as a requirement rather than as a problem :-)
So, the question remains: how can I tell what I would be getting if I bought TSE? Is the API documentation online? (Of course, it might be as sparsely filled out as the TGE documentation...)
#17
You raise a perfectly valid point about upgrading to TSE, and the answer is basically that you have to trust us. If the only reason you'd upgrade is for a better API, you might be in trouble anyway. If I was a TGE owner and looking to upgrade to TSE, I'd play with the demos for a while (lots of good things you can learn from demos), and find some TSE owners that I could ask questions of. I might try posting in the TSE public forums to see if people were happy with their purchase. Or maybe I'd go into IRC and ask after it.
Having some sort of doc or API preview is a good idea, but sadly low on our priority list at the moment - we're focusing more on bug fixes and feature completeness.
Ultimately TSE is more about what it can do than how its code is structured, although in this case, most objects submit their rendering state to a render instance manager rather than drawing themselves. So you'd probably be happier with it although we've purposely stayed away from a retained mode style setup.
Did you read the article I linked? This is a better link to the specific article, rather than the whole blog/wiki. I think it outlines pretty much _exactly_ what I think is bad about scene graphs, and _exactly_ what is meant by "scene graph" in that context. Tom Forsyth is a pretty smart guy, but despite that I actually agree with him on this point. ;)
09/17/2006 (9:55 pm)
Wow, way to hijack the topic. :PYou raise a perfectly valid point about upgrading to TSE, and the answer is basically that you have to trust us. If the only reason you'd upgrade is for a better API, you might be in trouble anyway. If I was a TGE owner and looking to upgrade to TSE, I'd play with the demos for a while (lots of good things you can learn from demos), and find some TSE owners that I could ask questions of. I might try posting in the TSE public forums to see if people were happy with their purchase. Or maybe I'd go into IRC and ask after it.
Having some sort of doc or API preview is a good idea, but sadly low on our priority list at the moment - we're focusing more on bug fixes and feature completeness.
Ultimately TSE is more about what it can do than how its code is structured, although in this case, most objects submit their rendering state to a render instance manager rather than drawing themselves. So you'd probably be happier with it although we've purposely stayed away from a retained mode style setup.
Did you read the article I linked? This is a better link to the specific article, rather than the whole blog/wiki. I think it outlines pretty much _exactly_ what I think is bad about scene graphs, and _exactly_ what is meant by "scene graph" in that context. Tom Forsyth is a pretty smart guy, but despite that I actually agree with him on this point. ;)
#18
I agree with Tom on a lot of the traditional "scene graph" problems -- especially the graphs that inherit attributes other than position from node parents.
A good scene graph, in my opinion, is something which is a full database of everything you want to render, and how to render it. When time comes to present the scene, the graph can traverse/sort/optimize however it wants, without asking the content objects, because it has full knowledge of what there is to do. Whether you do deferred shading, or stencil shadows, or some other technique in the rendering is almost entirely a scene graph property; the content objects just declare how they want to be rendered using references to data.
Anyway -- that's an old discussion. I've been doing graphics for ten years, and initially, I was die-hard immediate mode. It's only after having seen some really good, non-intrusive, retained-mode, "scene database" based scene graphs that I've come to appreciate that it can actually be done right, and then it helps a lot compared to immediate mode.
09/18/2006 (7:50 am)
Thanks for the reply.I agree with Tom on a lot of the traditional "scene graph" problems -- especially the graphs that inherit attributes other than position from node parents.
A good scene graph, in my opinion, is something which is a full database of everything you want to render, and how to render it. When time comes to present the scene, the graph can traverse/sort/optimize however it wants, without asking the content objects, because it has full knowledge of what there is to do. Whether you do deferred shading, or stencil shadows, or some other technique in the rendering is almost entirely a scene graph property; the content objects just declare how they want to be rendered using references to data.
Anyway -- that's an old discussion. I've been doing graphics for ten years, and initially, I was die-hard immediate mode. It's only after having seen some really good, non-intrusive, retained-mode, "scene database" based scene graphs that I've come to appreciate that it can actually be done right, and then it helps a lot compared to immediate mode.
Torque Owner Anton Bursch
There is no scripting for TorqueX, you will use c# directly, yes, probably to talk to a bunch of TorqueX library code and probably also application code, but you will be coding the source, not using scripting.
The demo shown of Marble Blast Ultra using xna was made with xna and c#.