TGEA 1.8 on a Mac
by Matt Fairfax · 09/20/2008 (2:13 am) · 50 comments
TGEA 1.8 runs on Macs!
Running TGEA on a MacAfter 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).
GFX2
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
StateBlocks
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!).
ShaderGen
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).
Constant Buffers
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:
GFX->setShaderVertexConstF(14, myConst);
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
About the author
#2
09/20/2008 (2:58 am)
Great post!!! TGEA + OSX = Moist and Delicious!
#3
09/20/2008 (3:20 am)
will AFX be added to this in due time?
#5
09/20/2008 (4:24 am)
I saw it with my own eyes. It really exists! Great work, looking forward to playing around with it.
#6
09/20/2008 (4:32 am)
Great work!
#7
09/20/2008 (7:11 am)
In the immortal words of Q*BERT : "@%!#!"
#8
Hmmm. .if it's out in 3-4 weeks..i hope the Afx integration comes out in the next few weeks after...
I've been thinking that a better approach for writing stuff with Torque is to really keep all my changes in 'new' classes which are cloned from the default classes (i.e. Player et al)....So that when cool stuff like this happens, we can roll it in with a minimal level of fuss...
For me, a big problem is sometimes that base classes needs changes (i.e. like pulling energy out of ShapeBase and sticking it somewhere else..our items don't have energy!)...ho hummm..good thing I didn't do that today...i guess WinDiff is your best friend then....
09/20/2008 (7:50 am)
Nooooooo!!!!....I'm am just in the middle of seriously changing some engine code as well with TGEA 1.7.2...Hmmm. .if it's out in 3-4 weeks..i hope the Afx integration comes out in the next few weeks after...
I've been thinking that a better approach for writing stuff with Torque is to really keep all my changes in 'new' classes which are cloned from the default classes (i.e. Player et al)....So that when cool stuff like this happens, we can roll it in with a minimal level of fuss...
For me, a big problem is sometimes that base classes needs changes (i.e. like pulling energy out of ShapeBase and sticking it somewhere else..our items don't have energy!)...ho hummm..good thing I didn't do that today...i guess WinDiff is your best friend then....
#10
09/20/2008 (8:25 am)
Linux???
#11
It might be that all this is 'your way of testing' the inns and outs of T2 (or whatEverItsNameWillBe) -but!
The ROI one gets from being here is incredible, and I really want to state how much I appriciate it. Thank you (folks@GG) so much for keeping the techs alive and handing back ROI that far exceeds what one could ever expect.
/CBLS
09/20/2008 (10:15 am)
Matt; Ive been around this place for app. 5 years and allways liked the engines, community and slappings enough to stick around to learn how to code so I can make 'something gamish'. Normally my opinion is that the raw engines combined with the community ressources is the real value of this place, but lately you guys at GG have made efforts to develop the 'old' tech that surely outshines what one would expect from the really small pile of greens one had to put out to get 'hands on'.It might be that all this is 'your way of testing' the inns and outs of T2 (or whatEverItsNameWillBe) -but!
The ROI one gets from being here is incredible, and I really want to state how much I appriciate it. Thank you (folks@GG) so much for keeping the techs alive and handing back ROI that far exceeds what one could ever expect.
/CBLS
#12
Even when having Mac support is nice, for the the most important thing with this update are the enhancements on the shader pipeline. Stateblocks were a must have (werent they available first in DX9?) and shader variable handler query are a real improvement. You are just a small step from handling semantics.
Congratulations.
P.S.
Please dont flame me if I say I would love to see some improvements in TGE also. It is slowly dragging behind all the other versions.
@Guy - You have a really twisted sense of humor you know... :)
09/20/2008 (12:23 pm)
Awesome!Even when having Mac support is nice, for the the most important thing with this update are the enhancements on the shader pipeline. Stateblocks were a must have (werent they available first in DX9?) and shader variable handler query are a real improvement. You are just a small step from handling semantics.
Congratulations.
P.S.
Please dont flame me if I say I would love to see some improvements in TGE also. It is slowly dragging behind all the other versions.
@Guy - You have a really twisted sense of humor you know... :)
#13
09/20/2008 (12:31 pm)
Wow. I am so speechless. All hail.
#14
This is the end of an anxious wait !
What about performance on Mac ? Does it run on powerPC Mac ?
NIcolas Buquet
www.buquet-net.com/cv/
09/20/2008 (12:43 pm)
Congratulations !This is the end of an anxious wait !
What about performance on Mac ? Does it run on powerPC Mac ?
NIcolas Buquet
www.buquet-net.com/cv/
#15
09/20/2008 (1:30 pm)
This is a major boost for TGEA. Congrats and can't wait to see it for myself. :-)Quote: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.ROTFL Right!! hahaha, you know better. It's in black and white now. LOL. (just ribbing you due to the fact that some, will inevitably take this time frame as hard coded fact.)
#16
I've honestly never would have thought that this would happen within 2-3 years. I'm not the ideal Mac fanboy, though I do work on a Mac, and I really like it. Overall, I am just really really really happy that my game will support both platforms now.
This is something I've given up when I chose TGEA for its enhanced gfx and faster rendering speed over TGE that had the option to publish on multiple platforms.
I wonder what the future holds for TGE now - is there still a reason not to switch to TGEA?
Congratulations to everyone involved in making this possible - and cheers to Michael, who still needs to write a truckload of docs. :)
09/20/2008 (2:17 pm)
Dang, just when I was becoming familiar with GFX.. :) j/kI've honestly never would have thought that this would happen within 2-3 years. I'm not the ideal Mac fanboy, though I do work on a Mac, and I really like it. Overall, I am just really really really happy that my game will support both platforms now.
This is something I've given up when I chose TGEA for its enhanced gfx and faster rendering speed over TGE that had the option to publish on multiple platforms.
I wonder what the future holds for TGE now - is there still a reason not to switch to TGEA?
Congratulations to everyone involved in making this possible - and cheers to Michael, who still needs to write a truckload of docs. :)
#17
But obviously, Matt would be the better source for this info.
09/20/2008 (3:43 pm)
I can't speak for Matt, but I'll echo what he told me at AGDC: performance on the Mac is excellent, perhaps even faster than on the PC. And there should be something like a 2-3-fold speed boost from TGE, I believe. And no, it will not run on PowerPC Macs. Only Intel-based.But obviously, Matt would be the better source for this info.
#18
09/20/2008 (3:49 pm)
Fantastic news!
#19
@Nicolas, Rubes: Technically there's nothing stopping you from running it on PowerPC Macs. However, I never put any effort into supporting them because 1) It's a rapidly shrinking user base, and 2) Apple didn't update their PPC drivers for close to two years. If you're willing to put up with two years of unfixed bugs on 10.4 PPC then PPC support is certainly possible. I'm not sure what the situation is like on 10.5 PPC.
@Rubes: Performance is quite good on Macs. There are situations where performance can suffer though, e.g. OS X drivers don't deal well with running low on VRAM, and since the OS uses VRAM for the windowing system you have a fair bit less to work with from the get go. That particular point was driven home hard during the game ports. If you've got an asset heavy game you'll need to do a lot of optimization to support 128 MB cards on OS X.
09/20/2008 (3:58 pm)
@Guimo: Actually, no. Stateblocks were first available, in D3D10. They do make a handy abstraction for us though which greatly simplified the D3D9 and GL GFX implementations.@Nicolas, Rubes: Technically there's nothing stopping you from running it on PowerPC Macs. However, I never put any effort into supporting them because 1) It's a rapidly shrinking user base, and 2) Apple didn't update their PPC drivers for close to two years. If you're willing to put up with two years of unfixed bugs on 10.4 PPC then PPC support is certainly possible. I'm not sure what the situation is like on 10.5 PPC.
@Rubes: Performance is quite good on Macs. There are situations where performance can suffer though, e.g. OS X drivers don't deal well with running low on VRAM, and since the OS uses VRAM for the windowing system you have a fair bit less to work with from the get go. That particular point was driven home hard during the game ports. If you've got an asset heavy game you'll need to do a lot of optimization to support 128 MB cards on OS X.
#20
09/20/2008 (5:34 pm)
Woot, cool to see this coming out! DX9 did have a stateblock object used to support their FX framework. But it wasn't core to DX9, so it was hard for them to implement them efficiently and I don't think it was widely used.
Associate Pat Wilson
I'm glad this is finally out in the open air. A significant amount of work has been put in to TGEA this year, and a lot of it has depended on other work. This update to TGEA is fantastic (besides the Mac stuff which is monumental). State blocks and constant buffers prevent many bugs that arise from bad states, or over-writing shader constants. The PIX output is so much easier to read since all shader constants are set in one call. You no longer have to skim through 20 lines of "setvertexshaderf" to find the call you are looking for. The rendering code is cleaner, and easier to follow without state calls scattered all over the place.
Hats off to Matt & Alex.