TGEA 1.8 on a Mac
by Matt Fairfax · 09/19/2008 (7:13 pm) · 50 comments
TGEA 1.8 runs on Macs!Running TGEA on a Mac
After years of research, we here at GarageGames have painstakingly come up with a surefire process to run TGEA a Mac! Here is the procedure:
1) First, be sure that you buy an Intel-based Mac (this is critical)
2) Next, install Boot Camp
3) Then install Windows Vista
4) Download and install Torque Game Engine Advanced
And there you go...TGEA on a Mac!
Running TGEA on OSX
What? Wait! When the hordes were demanding that we port TGEA to the Mac, that isn't what you meant?!? Ohhh....
Well...how about we release a new version of TGEA that is designed to run on a Mac under OSX?
Fortunately for you, we were showing off just that very thing at Austin GDC this past week:
TGEA 1.8 running on an iMac at AGDC
Tell me more!
TGEA 1.8 is the next version of TGEA that we will be releasing. It is a FREE update that is aimed primarily at adding OSX support to Torque Game Engine Advanced.
This is a culmination of years of work and research by Alex Scarborough starting with his impressive Modernization Kit. For the last year or so, Alex has been hard at work hacking in a quick OpenGL shader solution into our InstantAction games like Fallen Empire: Legions, Rokkitball, Marble Blast Online, and ThinkTanks so that they are all playable on the Mac version of InstantAction. When he wasn't doing that, he was taking the lessons he learned from that and adding a proper OpenGL Shader layer to our cutting edge research and development engine ("Torque R&D" for now).
For the last several months I have been hard at work at merging the next generation of GFX from Torque R&D back into TGEA. This means that we will be picking up a few things more than just an OpenGL layer. It also means that we will be able to directly benefit from the hard work and experience that GG Studios is putting into their next round of games.
You can use the Project Generator on OSX to create your Xcode project
One of the fundamental changes that GFX2 introduces is the concept of StateBlocks. This is actually something that we borrowed from DirectX 10 and have implemented in software for the DirectX9 and OpenGL layers for now. The basic idea is that an active rendering state is contained in one object and you are able set that rendering state with a single call. The state that you set fully defines the render state. So the idea of a cannonical render state is gone. Which is good, your rendering worries about defining its own state and that's it. This should greatly reduce bugs that are introduced because state hasn't been cleaned up by a previous rendering object/pass (this is the cause of a lot of the graphical glitches you see in Torque and other engines).
Let me break this down into an example. In the past we might have done something like:
// Render time code GFX->setBlendEnable(true); GFX->setBlendDest(GFXInvSrcAlpha); GFX->setBlendSrc(GFXSrcAlpha);
Now, when we are setting up our object we do this:
// Setup code, done once GFXStateBlockDesc desc; desc.setBlend(true, GFXSrcAlpha, GFXInvSrcAlpha); GFXStateBlockRef myState = GFX->createStateBlock(desc);
And then when we render we can make a single call and it properly sets up the entire rendering state:
// Render time code GFX->setStateBlock(myState);
This practically eliminates state bugs and what is even cooler is that when we make the switch to DirectX 10 this will all be hardware driven (fast!).
One of the great things about GFX2 is that it has a proper GLSL ShaderGen implementation. This means that if you use Materials on your object (currently defined in script) then they will automatically work on both Windows and Mac. This can save your team and project a ton of time and make it so that your port to OSX is fairly trivial.
Use a Material and your shaders will just work on Windows and Mac
You can use CustomMaterials to specify your own hand written HLSL and/or GLSL shaders (if you want to remain cross-platform compatible you'll have to implement both for CustomMaterials).
Another big change that GFX2 brings with it is Constant Buffers. Instead of just "knowing" which register maps to which shader variable, in GFX2 you query the shader for a list of variables and then bind to them by name.
For example, previously if I wanted to set a float to the shader variable scaleLighting, I would have something like this in the shader:
uniform float scaleLighting : register(C14)
and this in my C++ code:
I would have to know ahead of time that the shader was expecting my value to be in the 14th register and to bind it there. Instead with GFX2, I just query the shader for its "scaleLighting" variable and it hands back a handle for me no matter what register it is bound to.
At load time, I would have something like:
// Setup code GFXShaderConstBuffer* myBuff = shader->allocConstBuffer(); GFXShaderConstHandle* myHandle = shader->getShaderConstHandle("$scaleLighting");
And then, when I rendered, I would have:
// Render code myBuff->set(myHandle, myConst); GFX->setShaderConstBuffer(myBuff);
This allows us to end up with a lot less mismatches between what the shader expects and what we are sending it and has the potential to allow the drivers to do some optimization on the shaders which could change which registers are bound to which variables.
Porting and Documentation
We know this is a lot of changes and it is going to be a bit daunting if you have GFX rendering code that needs porting over to GFX2. That is why our documentation guru, Michael Perry, is already hard at work on a general overview doc for GFX2 and a lot of porting docs and tutorials to help smooth your transition. It is also the reason that we tried to limit most of the changes between TGEA 1.7.1 to TGEA 1.8 to things that GFX2 directly relies on.
Check out a quick walkthrough of T3D on a Mac at AGDC...be sure to watch all the way to the end =)
When do we get it?!?!!
As you can see from the screenshots and videos we have a lot of the initial integration done. However, we do have few more big systems to work through and a ton of smaller spots (mostly StateBlock related) spots to finish merging over.
Our goal is to provide TGEA owners with access to a Beta some time in the next 3-4 weeks. As always, this is only an estimate and shouldn't be taken as a hard and fast deadline. We will be sure keep you posted on the progress if we aren't going to hit this estimate though.
We are really excited to finally provide this to you guys and that it is everything that it should be and that it is FREE!
If you are looking for more information you can read more over in the IRC Hour Chat Log