XNA 3.1 and TX 3.1....Does it work or not?
by Shane Hamlin · in Torque X 3D · 08/12/2009 (1:12 pm) · 29 replies
I'm reading there has been an update to TX3D to get it running with XNA 3.1...
But I've yet to see an update I can download being in the XNA Creators Club.
WHEN WILL WE SEE THIS?
So for those of you who have actually purchased the product...
IS there a TX3D that works with XNA 3.1?
When are we going to see an update?
I check back here on the website so often...Always hopeful...Always leave the website dissappointed. :(
But I've yet to see an update I can download being in the XNA Creators Club.
WHEN WILL WE SEE THIS?
So for those of you who have actually purchased the product...
IS there a TX3D that works with XNA 3.1?
When are we going to see an update?
I check back here on the website so often...Always hopeful...Always leave the website dissappointed. :(
#22
That makes a hell of a difference and a lot more sense.
Although I’m not even close to a game, I guess it could be useful. We never know.
If you could give me an example where it could be useful, I’d appreciate it. Nothing evolved, just a simple thing to give me an idea. Something to make me feel good about the 250 bucks :|
08/29/2009 (6:56 pm)
Thanks John,That makes a hell of a difference and a lot more sense.
Although I’m not even close to a game, I guess it could be useful. We never know.
If you could give me an example where it could be useful, I’d appreciate it. Nothing evolved, just a simple thing to give me an idea. Something to make me feel good about the 250 bucks :|
#23
08/29/2009 (9:52 pm)
You will also see the engine source section inside of the solution in VS.
#24
For me, it's largely a split between education, debugging, and extensibility.
I went from knowing nothing about Torque X to understanding (nearly) every piece of code and then ultimately writing the book on Torque X, solely by dissecting the code. I took one module at a time, starting with the components, and ended with shaders and vertex buffers. Because the C# language is clear and readable, you can learn how the scene graph and rendering code works. Conversely, I've dissected the TGE code in C++ and my head started spinning with the multiple levels of pointer referencing & dereferencing across a large class library. I do not miss C++ header files one bit.
Debugging a Torque X game on the Xbox 360 brings (for me) tears of joy. You can set breakpoints in Torque X engine code and step-debug through game code and rendering code running on the Xbox - wow!. Just a couple years ago, it took a $10,000 black Xbox 360 Dev Console to do this. Solving problems in my game code goes so much faster now.
Extensibility is also much easier now. Usually you don't need source code to inherit from an existing class framework. But sometimes you do - some of the Torque X class methods are marked sealed for performance reasons and you need to remove that modifer in order to override them in derrived classes. In other cases, it's more effective to change the base class than to inherit a new class, especially if you wanted to incorporate your own core services, like integrating Bullet Physics or FMod (for Windows only). There's also a lot of great resources on this site and on the XNA site that you might want to integrate directly into the engine. When I (and a few others) come across engine fixes and mods, we post the source code here for anyone to include it.
Is all that worth $250? Maybe not, maybe so. It has been for me, but I also completely respect others who only want to focus on the game code and not think about the underlying engine details. In that case, it's likely not worth $250. In the end, it's all about making games, having a good time, learning something new, and maybe making some money from our projects ;)
Oh, one more small thing, all of the demo projects that come with the Pro version also have the full engine source code within their solutions - whereas the free binary versions of those demos only point to the Torque X assembly in the GAC. That's one more place you'll find the source code.
John K.
www.envygames.com
08/30/2009 (4:54 am)
Robert,For me, it's largely a split between education, debugging, and extensibility.
I went from knowing nothing about Torque X to understanding (nearly) every piece of code and then ultimately writing the book on Torque X, solely by dissecting the code. I took one module at a time, starting with the components, and ended with shaders and vertex buffers. Because the C# language is clear and readable, you can learn how the scene graph and rendering code works. Conversely, I've dissected the TGE code in C++ and my head started spinning with the multiple levels of pointer referencing & dereferencing across a large class library. I do not miss C++ header files one bit.
Debugging a Torque X game on the Xbox 360 brings (for me) tears of joy. You can set breakpoints in Torque X engine code and step-debug through game code and rendering code running on the Xbox - wow!. Just a couple years ago, it took a $10,000 black Xbox 360 Dev Console to do this. Solving problems in my game code goes so much faster now.
Extensibility is also much easier now. Usually you don't need source code to inherit from an existing class framework. But sometimes you do - some of the Torque X class methods are marked sealed for performance reasons and you need to remove that modifer in order to override them in derrived classes. In other cases, it's more effective to change the base class than to inherit a new class, especially if you wanted to incorporate your own core services, like integrating Bullet Physics or FMod (for Windows only). There's also a lot of great resources on this site and on the XNA site that you might want to integrate directly into the engine. When I (and a few others) come across engine fixes and mods, we post the source code here for anyone to include it.
Is all that worth $250? Maybe not, maybe so. It has been for me, but I also completely respect others who only want to focus on the game code and not think about the underlying engine details. In that case, it's likely not worth $250. In the end, it's all about making games, having a good time, learning something new, and maybe making some money from our projects ;)
Oh, one more small thing, all of the demo projects that come with the Pro version also have the full engine source code within their solutions - whereas the free binary versions of those demos only point to the Torque X assembly in the GAC. That's one more place you'll find the source code.
John K.
www.envygames.com
#25
What kind of game are you interested in making? I'm happing to offer some pointers or direction.
John K.
www.envygames.com
08/30/2009 (4:54 am)
Robert,What kind of game are you interested in making? I'm happing to offer some pointers or direction.
John K.
www.envygames.com
#26
09/02/2009 (2:14 am)
Having the source helped me a lot in debugging. When I would get an error that appeared in the Torque source I was was able to trace it back to my passing in something wrong, and being to able to see what the engine was looking for. Does that make sense? It was really helpful.
#27
What a nice explanation! I definitely want to keep them sources now. I do like to go deeper some times because I always need that special something that I can't do any other way. And the debug can sure be useful as Henry also pointed out.
Game type: Puzzle solving
That's a hard one to explain without giving it away. Let’s just say that everything happens inside full 3D rooms of different sizes that we can view from anywhere at any angle and one room at a time for each level. The same room can be use more then once. A galore of ordinary objects (some with magic powers maybe) with fully integrated physics will be needed like weight, heat, wind, water, fire and explosions with smoke! Objects found or created will be stored in an inventory for later/immediate use. The inventory has to be very sophisticated and able to handle mechanics to join parts together to create totally new objects needed in later puzzles. It can be anything. Those objects and their environments are the heart of the game and all needs to look as real as possible. The Inventory system will take a big part in the game. I want the player to feel like he’s really inside those rooms. Not for claustrophobics
I think I might need a level editor to put all this together. But that’s a whole other animal.
I just added ShowTool Pro to my arsenal. Now I’m looking into Blender, Houdini or some other modeler to create all this stuff. I really would like to use Houdini but nobody knows about what it can or can not export. I guess it goes with all those tools… So I’m kinda stuck there right now.
I really appreciate your offer and I’m pretty sure I’m gonna need it :)
Thanks a lot!
@Henry
Thanks! That helped a lot also ;)
Now I feel like a little bunny jumping around again.
Edit:
I just registered the site for it: the-inventor.net (nothing there yet)
The Inventor will be the name of the game (if all is well)
09/02/2009 (8:07 am)
@John,What a nice explanation! I definitely want to keep them sources now. I do like to go deeper some times because I always need that special something that I can't do any other way. And the debug can sure be useful as Henry also pointed out.
Game type: Puzzle solving
That's a hard one to explain without giving it away. Let’s just say that everything happens inside full 3D rooms of different sizes that we can view from anywhere at any angle and one room at a time for each level. The same room can be use more then once. A galore of ordinary objects (some with magic powers maybe) with fully integrated physics will be needed like weight, heat, wind, water, fire and explosions with smoke! Objects found or created will be stored in an inventory for later/immediate use. The inventory has to be very sophisticated and able to handle mechanics to join parts together to create totally new objects needed in later puzzles. It can be anything. Those objects and their environments are the heart of the game and all needs to look as real as possible. The Inventory system will take a big part in the game. I want the player to feel like he’s really inside those rooms. Not for claustrophobics
I think I might need a level editor to put all this together. But that’s a whole other animal.
I just added ShowTool Pro to my arsenal. Now I’m looking into Blender, Houdini or some other modeler to create all this stuff. I really would like to use Houdini but nobody knows about what it can or can not export. I guess it goes with all those tools… So I’m kinda stuck there right now.
I really appreciate your offer and I’m pretty sure I’m gonna need it :)
Thanks a lot!
@Henry
Thanks! That helped a lot also ;)
Now I feel like a little bunny jumping around again.
Edit:
I just registered the site for it: the-inventor.net (nothing there yet)
The Inventor will be the name of the game (if all is well)
#28
I really like the sounds of that game and the title. Here's what I'm thinking...
Modeling
I have an older version of 3D Studio Max, it's crazy expensive but worth it. I also have Houdini, but was frustrated by its complex and messy licensing system. By the time I was able to actually run it, I was burned out with it (and I have a lot of patience). XSI ModTool is FREE and is pretty good. It natively outputs an .XSI file, which Torque X can render using the T3DXsiRenderComponent - but not animate. I highly recommend you look at this if your room objects do not animate. If they do, then new code needs to be added to animate them (I think) or find another tool and produce .DTS files. Blender is good and I place Milkshape 3D last.
The Room
The room can be a static shape component, using T3DStaticTSRenderComponent. This gives you surface polysoup collisions. To get "real as possible", you'll need really good textures for the room, with normal maps. You should also try to give the room as much detail as possible: window/door casing, door trim, base boards, maybe even a little mouse hole - anything that will help cast a shadow. You might experiment with fog in the room, not bright or thick, just enough to soften the corners and make the room 'feel' muggy.
The Camera
You didn't mention if there is a player avatar in the room, or if you just fly with the camera (you don't need to). Either way, it will need a sphere collision shape to collide with the walls of the room and possibly the 3D objects in the room.
The Inventory
This is my favorite part!!! Up to this point the comments earlier could apply to any game. I think this is where the IP of your game exists, so I'll respect your concept and ask you to email me directly for thoughts on this (address is in the profile page).
You should definitely start by dissecting the FPS Demo project. It's burried somewhere under \Program Files\GarageGames\Torque X\3\Demos (or something like that). The FPS game has a lot of the foundation elements you need.
John K.
www.envygames.com
09/02/2009 (1:31 pm)
Robert,I really like the sounds of that game and the title. Here's what I'm thinking...
Modeling
I have an older version of 3D Studio Max, it's crazy expensive but worth it. I also have Houdini, but was frustrated by its complex and messy licensing system. By the time I was able to actually run it, I was burned out with it (and I have a lot of patience). XSI ModTool is FREE and is pretty good. It natively outputs an .XSI file, which Torque X can render using the T3DXsiRenderComponent - but not animate. I highly recommend you look at this if your room objects do not animate. If they do, then new code needs to be added to animate them (I think) or find another tool and produce .DTS files. Blender is good and I place Milkshape 3D last.
The Room
The room can be a static shape component, using T3DStaticTSRenderComponent. This gives you surface polysoup collisions. To get "real as possible", you'll need really good textures for the room, with normal maps. You should also try to give the room as much detail as possible: window/door casing, door trim, base boards, maybe even a little mouse hole - anything that will help cast a shadow. You might experiment with fog in the room, not bright or thick, just enough to soften the corners and make the room 'feel' muggy.
The Camera
You didn't mention if there is a player avatar in the room, or if you just fly with the camera (you don't need to). Either way, it will need a sphere collision shape to collide with the walls of the room and possibly the 3D objects in the room.
The Inventory
This is my favorite part!!! Up to this point the comments earlier could apply to any game. I think this is where the IP of your game exists, so I'll respect your concept and ask you to email me directly for thoughts on this (address is in the profile page).
You should definitely start by dissecting the FPS Demo project. It's burried somewhere under \Program Files\GarageGames\Torque X\3\Demos (or something like that). The FPS game has a lot of the foundation elements you need.
John K.
www.envygames.com
#29
Thanks.
09/04/2009 (5:49 am)
I can't find your email so I activated mine. Just send me one so I can reply.Thanks.
#30
John K.
www.envygames.com
09/04/2009 (1:56 pm)
Really? Sorry about that... I haven't checked since the GarageGames Website re-design. Anyway, it's jkanalakis@envygames.com. I'll send you a message too.John K.
www.envygames.com
Associate John Kanalakis
EnvyGames
There is not a specific source code folder for the paid version of Torque X. Rather, when you create a new game project and choose the 'Pro' template, a new solution is created with a game project and two other Torque X related projects which contain the full source code.
John K.
www.envygames.com