Aspyr On Porting Games to the Mac

jvm writes "This in-depth interview with Aspyr's Glenda Adams over at Curmudgeon Gamer discusses in detail the issues of porting games to the Mac. Starting with Civilization on the Mac LC up through today's Tony Hawk Pro Skater 4, Glenda takes on PC vs. Mac system requirements, how games are selected for porting, patching Mac games, and some thoughts on the future." A notable quote from the interview: "The PC often lets you [code/architect] things in a sloppy manner with little penalty, but then when it gets on the Mac it drags the game down."

Comments

Blitz Max

[Anonymous Coward]

Blitz Max is due out this year for Windows, OS X and Linux, all using OpenGL. The current Windows version will give an idea of what will be possible (it's fast, and Max will have OO features in addition):

Blitz Basic

PC Architecture

[Detritus]

I'm curious about what the problems mentioned in the article are, sloppy code that runs with a slight penalty on the PC and falls over on the Mac. My Mac has a reasonable number of MIPS (2 x 450 MHz G4), but most ports of PC games are barely playable.

Re:PC Architecture

[netfunk]

Converting a number between floating point and integer on Macs is actually quite expensive compared to x86 systems. Converting between double and float has a severe penalty, too.

Also, Macs tend to suffer a worse penalty for CPU cache misses.

Then again, there's a handful of general purpose registers on an x86, and 64 of them on the PPC (96 if you count the Altivec registers), so it's assumed that x86 systems will optimize for these cases more than the PPC, whereas the PPC assumes you'll load what you need into registers, work on it, and go back to RAM only when absolutely forced to. This means you should define a bunch of local variables, and load as much as possible into them at the start of a function. On the PPC, this can be several orders of magnitude faster, whereas on the x86, it might be a little slower (since those locals won't translate into registers, you end up shuffling between the heap and stack and working out of RAM anyhow).

Pre-G5, there's no square root instruction on the CPU. You can fake it with the fsqrtre opcode (which all Macs have, but I believe is optional in the PPC spec, too), but this gives you extremely low precision (five bits...you can actually GUESS with more precision!), but it's fast (and frequently "good enough" after two rounds of newton-raphson)...we used this (with Newton-Raphson) in UT2003/UT2004 without any noticable rendering artifacts. The G5 has a real, full-precision square root instruction, which spanks the cheap reciprocal method to boot, but will crash your program (SIGILL) on a G4 or lower. If you just call the system's C library's sqrt(), it'll do the right thing based on the running CPU, but to give you real precision, it won't using the reciprocal opcode...so on a G5, sqrt() gives good performance, on a G4, it'll eat up tons of CPU. The flyby intro on the original Unreal Tournament was spending about 17-20% of it's CPU time in sqrt() until I swapped in the reciprocal version.

While I'm talking about sqrt(), a lot of other things developers take for granted on their x86 floating point unit, like sin(), aren't implemented in hardware on the PPC.

Division on the PPC causes a complete pipeline stall (use multiplication where possible). GCC doesn't appear to optimize this case behind the scenes at this point.

On the G5, instructions are broken up into "dispatch groups"...usually five instructions, I think, but it varies due to a few factors. If you write to a memory address and read it back in the same dispatch group, it causes a pipeline stall. This is called an "LSU reject". Developer documentation says that in these cases you should either move the store and load to seperate dispatch groups, or at least pad out the dispatch group with no-ops so the load will be in a different group. GCC doesn't doesn't necessarily optimize this for you at this point, but I'm not sure where Apple's GCC branch lies in relation to the mainline version (which can now handle this).

LSU rejects are, however, a somewhat common optimization gotcha: // An untested example:
static int myvar1; // force out of register.
myvar1 = somefunc(); // store.
int myvar2 = myvar1 + 10; // read.

The solution is to move the addition down a few lines of code so that the compiler doesn't put it in the same dispatch group...padding out with no-ops isn't really practical, and it's something the compiler should be doing anyhow. More to the point, your x86 developer isn't going to think something as harmless as having those two lines next to each other would be an optimization issue. Why should he?

Optimizations "truths" of the x86 aren't necessarily true on the PowerPC, either:

1) Loop unrolling is generally believed to be a "good optimization" on the x86, but it thrashes your instruction cache on the PPC. Actually, this is probably true on modern x86 chips nowadays, too, but on the PPC, Cache Is King.

2) Lookup tables are generally believe

Re:PC Architecture

[Tomah4wk]

Loop unrolling in most cases i have played with it on the P4 also slows programs down (albiet not hugely) and i had also attributed this to the instuction cache. In fact the only time i have seen it to be beneficial is with a really tight (i.e. one line of code) loop where we new how many times the loop would be executing almost all of the time and used a pragma to advise the compiler (intel c++) of this.

A VM always helps.

[Domini]

Writing a game to use a virtual machine and some form of quasi interpreted code always makes portability a near given.

See this site: http://this.is/vortex/osx-ports/?action=games
for games 'ported' to OS X using the scumm vm. (Some cool ones!)

Also note how seamlessly Quake 3 runs on even a slow iBook 900 G3.

Other games which also ported nicely would be Warcraft III and Neverwinter Nights.

This is mainly due to the programmer showing some foresight.

The only problem is that the Mac version of Neverwinter Nights is out only recently, when all my multiplayer PC friends area already tired of playing it, and it costs about 8 times the price of the current Neverwinter Nights PC version, as well as the fact that it's difficult to get the expansions running for a normal home user, and ALSO the fact that I am unable to purchase the game AT ALL locally and the US and GB amazon stores don't ship here and Paypal does not support my currency.

AND THEN THEY COMPLAIN THAT THE PORTED VERSION DOES NOT SELL!!!!

I own the game on PC already, so why buy it twice? Warcraft 3 AND Quake3 runs on both nearly out of the box.

No, it's all up to sloppy marketing and programming. Don't blame the OS or the users.

Microsoft the savior?

[mactari]

The most interesting answer to me that I got from Glenda was with respect to crossplatform technologies. I'd recalled that she'd used OpenAL a number of times. And of course Apple created a decent OpenGL implementation thanks in part to John Carmack's influence. The DirectX to OpenXL porting route is right common nowadays. Wouldn't it be great if it were easier for programmers to *start* with these xplat techs and make ports trivial processes, like Quake 3 was?

But Glenda didn't put much stock in xplat techs becoming easier to use than M$ sellout techs, nor did she see Apple throwing more weight behind their use a solution.

But in true "forest for the trees" fashion, she pointed out the one potential savior for people gaming on "second tier" platforms, let us say, that I'd completely missed.

ruffin: Who else could run with the ball to get mature, cross platform game programming APIs written?

GA: Microsoft, but I don't see why they would want to.

It's sad that the M$ monopoly in the desktop OS market is so, "That's just the way it is," that I would have completely overlooked the answer. That's great insight -- though awfully obvious -- and the perfect "hit-home" reason for us gamers to be pretty angry with the folks in Redmond the way AOL/Netscape, Apple, Sun, and friends are.

I'm hoping to get a editorial based on the interview up soon, but at the same time to keep out the bile and trying to stay relatively objective and fair. That's proving tough.

And at the same time, the porting system is awfully broken. As games get larger and larger, who knows, perhaps taking multiple DVDs instead of multiple CDs (or obscenely long download times via the net), porting all that code isn't going to get any easier.