NextGen Gaming In TGEA
by Gerhard Botha · in Torque Game Engine Advanced · 09/21/2008 (5:44 am) · 52 replies
Hi,
I want to start a new topic on next-gen gaming in TGEA.
Please post your ideas/discussions on things like,
Does TGEA provide an extendible basis to work from?
What new features are important to add to TGEA?
How does TGEA compare to the Crytek Engine and UE3 engine?
When are we going to see someone make something like GOW/GOW2 using TGEA (very possible if you ask me)
I have had many arguments over a beer or two about technology requirements to make certain games like
the ones using UE3 for example. My basic thought is that you can use UE3 tech and still end up making a crap game, in fact just go look on gamespot at some of the new releases and you'll see what I mean. A good game engine will provide certain 'expected' functionality like a rendering pipeline, collision detection system etc. but any unique kind of game usually have unique requirements which does not come in an 'out of the box' solution implying a development effort on the game developer's side.
It seems TGEA has a bit of a hobbyist's only engine' mentality attached to it, which I find quite astonishing! Granted, it will be difficult to convince developers with a budget for engine acquisition not to use something like UE3 giving the massive amount of success stories tied to it but it obviously comes at a steep price!
Anyways, I think you get the idea. Myself and Ruan van der Westhuizen has embarked on a mission to investigate next-gen possibilities in TGEA since the start of this year and have done some things in our spare time using TGEA.
Go have a look at our blogs,
tgeaenhanced.blogspot.com and ruanwest.blogspot.com
I want to start a new topic on next-gen gaming in TGEA.
Please post your ideas/discussions on things like,
Does TGEA provide an extendible basis to work from?
What new features are important to add to TGEA?
How does TGEA compare to the Crytek Engine and UE3 engine?
When are we going to see someone make something like GOW/GOW2 using TGEA (very possible if you ask me)
I have had many arguments over a beer or two about technology requirements to make certain games like
the ones using UE3 for example. My basic thought is that you can use UE3 tech and still end up making a crap game, in fact just go look on gamespot at some of the new releases and you'll see what I mean. A good game engine will provide certain 'expected' functionality like a rendering pipeline, collision detection system etc. but any unique kind of game usually have unique requirements which does not come in an 'out of the box' solution implying a development effort on the game developer's side.
It seems TGEA has a bit of a hobbyist's only engine' mentality attached to it, which I find quite astonishing! Granted, it will be difficult to convince developers with a budget for engine acquisition not to use something like UE3 giving the massive amount of success stories tied to it but it obviously comes at a steep price!
Anyways, I think you get the idea. Myself and Ruan van der Westhuizen has embarked on a mission to investigate next-gen possibilities in TGEA since the start of this year and have done some things in our spare time using TGEA.
Go have a look at our blogs,
tgeaenhanced.blogspot.com and ruanwest.blogspot.com
#42
09/26/2008 (8:09 am)
There's no way new features will go into 1.8 at this point (if GG is smart about it). Version 1.8 is pushing towards Beta which means "no new features, only bug fixes." The other barrier to getting Gerhard's changes into the engine is that they seem to be built around DX functionality. I'm not sure if the techniques he's used have an equivalent in OpenGL, but GG now has to be careful the ensure that everything they implement will also work in an OpenGL/Mac environment otherwise they will hear it from the all-too-vocal OpenGL crowd.
#43
Building abstraction layers has its obvious advantages and disadvantages. Obvious advantage is that by using an abstraction layer one could code for both openGL and DirectX in one go and have a wider offset market (both PC and MAC). However, abstraction layers due to the complexity involved in abstracting code specific implementations like DirectX and OpenGL do tend to end up rather generic, which is usually the intention. But they more often than not hide the advanced or 'nice to have' features of a specific architecture like openGL and Direct3D has to offer.
I guess the worst 'hackery' I'm guilty of in TGEA is the raw use of Direct3D and HLSL FX for some of the things I (very rarely) do. Now this obviously would pose a problem in an environment supporting both OpenGL and DirectX because this breaks away from the abstraction tier. Not a crisis, Effect files can be converted to raw shader implementations. Something I'd like to see in TGEA is support for HLSL FX for both OpenGL and Direct3D (like FXComposer does) because I'm lazy (just joking!). Anyone who ever converted FX code to raw shader implementations would know that it is rather demoralizing to deal with all the extra implementation overhead. It is rather convenient to pack everything up into techniques which could be set on the fly etc. It also allows for easy pass flow control logic, will not go into too much detail here. Then again HLSL Effects is not suited for everything... Having said this however consider the complexities in the implementation of such an idea. For one, HLSL Effects has the ability to set render states inline when defining a technique. This has the potential to throw your render states into disarray in TGEA. Consider the following (naughty, I know...) scenario,
m_MyEffect->SetTechnique("StoreVertexPositionsToTexture");
...
GFX->drawPrim.....
...
GFX->setZWriteEnable( false );
Assume that ZWriteEnable was false before executing the technique and that the technique internally enables Z-buffer writing. Calling GFX->setZWriteEnable( false ); after executing the technique will still leave the z-buffer write render state true because TGEA's internal state still has it recorded as false and subsequent calls of GFX->setZWriteEnable( false ) would be ignored, only when calling GFX->setZWriteEnable( true ); would the hardware an TGEA's state be in sync again.
So adding features let alone abstract them for different rendering implementations can be a tedious task. Hats of to the people at GG for bringing OpenGL into the world of TGEA!
So where am I going with all of this? Nowhere, just throwing things up in the air for the sake of interesting conversation, lol...
09/30/2008 (3:13 am)
Interesting comment about OpenGL. I have never used TGE only TGEA so the closest I've ever come to OpenGL in TGEA are the traces/remnants of old green, commented openGL code in TGEA 1.0! As far as openGL support is concerned, this is supposed to be handled by the GFX tier. A developer using a version of TGEA with OpenGL support should not have to make extravagant code changes to support both OpenGL and DirectX. There should exist a proper abstraction tier above OpenGL and DirectX code specific implementations. Having said this, I have no idea what the current openGL changes has done to the GFX tier. Will probably have to migrate my code in order to make provision for these changes.Building abstraction layers has its obvious advantages and disadvantages. Obvious advantage is that by using an abstraction layer one could code for both openGL and DirectX in one go and have a wider offset market (both PC and MAC). However, abstraction layers due to the complexity involved in abstracting code specific implementations like DirectX and OpenGL do tend to end up rather generic, which is usually the intention. But they more often than not hide the advanced or 'nice to have' features of a specific architecture like openGL and Direct3D has to offer.
I guess the worst 'hackery' I'm guilty of in TGEA is the raw use of Direct3D and HLSL FX for some of the things I (very rarely) do. Now this obviously would pose a problem in an environment supporting both OpenGL and DirectX because this breaks away from the abstraction tier. Not a crisis, Effect files can be converted to raw shader implementations. Something I'd like to see in TGEA is support for HLSL FX for both OpenGL and Direct3D (like FXComposer does) because I'm lazy (just joking!). Anyone who ever converted FX code to raw shader implementations would know that it is rather demoralizing to deal with all the extra implementation overhead. It is rather convenient to pack everything up into techniques which could be set on the fly etc. It also allows for easy pass flow control logic, will not go into too much detail here. Then again HLSL Effects is not suited for everything... Having said this however consider the complexities in the implementation of such an idea. For one, HLSL Effects has the ability to set render states inline when defining a technique. This has the potential to throw your render states into disarray in TGEA. Consider the following (naughty, I know...) scenario,
m_MyEffect->SetTechnique("StoreVertexPositionsToTexture");
...
GFX->drawPrim.....
...
GFX->setZWriteEnable( false );
Assume that ZWriteEnable was false before executing the technique and that the technique internally enables Z-buffer writing. Calling GFX->setZWriteEnable( false ); after executing the technique will still leave the z-buffer write render state true because TGEA's internal state still has it recorded as false and subsequent calls of GFX->setZWriteEnable( false ) would be ignored, only when calling GFX->setZWriteEnable( true ); would the hardware an TGEA's state be in sync again.
So adding features let alone abstract them for different rendering implementations can be a tedious task. Hats of to the people at GG for bringing OpenGL into the world of TGEA!
So where am I going with all of this? Nowhere, just throwing things up in the air for the sake of interesting conversation, lol...
#44
It will be interesting on me to see a working texture fetch water on TGEA.
10/02/2008 (8:03 am)
Gerhard, job well done.It will be interesting on me to see a working texture fetch water on TGEA.
#45
11/02/2008 (1:05 am)
Amazing stuff..im gobsmacked.
#46
12/30/2008 (7:37 pm)
Just wondering if the NextGen technology will appear in TGEA 3D? 
#48
12/30/2008 (8:46 pm)
@Steven: The short answer is yes. Watch the Torque 3D development blogs for more details.
#49
12/31/2008 (6:03 am)
Simply awesome! I think my credit card is ready for this great upgrade... 
#50
In my opinion the biggest difference between TGEA and your Crytek/UE engines isn't the engine, but rather the tools/support/documentation. Having spent some time working with UE3, and also TGEA, I know that there's really not much that you can do with UE3 that you can't do with TGEA with relatively minimal effort from the aspect of integrating it into the engine. It's just that for doing anything other than the basics you really have to build your own tools and try to decipher the source code and file formats with limited documentation enough to implement them. Of course, for the price it's to be expected, and the community is great. For a million dollar savings I think we can handle building a few tools.
01/01/2009 (6:22 am)
Sweet stuff. I've been working on some stuff like this as well.In my opinion the biggest difference between TGEA and your Crytek/UE engines isn't the engine, but rather the tools/support/documentation. Having spent some time working with UE3, and also TGEA, I know that there's really not much that you can do with UE3 that you can't do with TGEA with relatively minimal effort from the aspect of integrating it into the engine. It's just that for doing anything other than the basics you really have to build your own tools and try to decipher the source code and file formats with limited documentation enough to implement them. Of course, for the price it's to be expected, and the community is great. For a million dollar savings I think we can handle building a few tools.
#51
01/01/2009 (10:18 am)
I second your idea about the engine and appreciate any improvement you've made for this great community!
#52
For those of you interested in implementing these features into TGEA, you may want to look at the following examples (including code) from the nVidia SDK 10.5
01/21/2009 (8:41 am)
This is very nice work, Gerhard.For those of you interested in implementing these features into TGEA, you may want to look at the following examples (including code) from the nVidia SDK 10.5
Torque Owner James Brad Barnette
3Dmotif LLC