Bringing Games to Intel Macs

...And who better to test these games.... ;-)

Interesting that the article mentions things like byte-swapping (green vlc, anyone?) but very little about the 3d acceleration so central to these games.. Are they still living with GMA900?

Apple has published an article on Aspyr's (maker of Sims 2, Doom 3, and others) efforts to begin porting their software to x86 binaries.

 

It gives us an interesting (if not entirely predictable) look at how software companies are charting their way through the transition.

 

Read the full article here.

Hmmm... You'd think Apple would start making certain that their display drivers were working alot better before doing something like this. I'd hope to see ATI and/or Nvdia start publishing SOMETHING... I don't think that a built-inintel 900 is going to cut it for most games...

Hmmm... You'd think Apple would start making certain that their display drivers were working alot better before doing something like this. I'd hope to see ATI and/or Nvdia start publishing SOMETHING... I don't think that a built-inintel 900 is going to cut it for most games...

Neither I, I hope nvidia and ati are reading this to create new drivers for this OS X in order to get a better mac gaming platform.

In addition to the explicit byte-swapping code required by the Intel to PowerPC conversions, many OpenGL-based games rely on Apple-specific extensions that automatically byte-swap texture data in the video card and its driver.

 

According to Glenda, “it took a few tweaks to the rendering code to stop having everything drawn in red!” This is in reference to a frequent problem with byte-swapping errors in OpenGL texture handling code, where colors display incorrectly.

Is that why PPC apps (such as Quicktime) that draws to QE (Quartz Extreme) usually screws up the pallete?

I believe It's more an OpenGl problem than Quartz, but I'd assume yes.

Oh, goody! Once the game developers start releasing stuff we will be in a great position. Game developers are notoriously sloppy about protecting their code which is why software protection schemes rely on bolt-on modules. Games are usually cracked pretty quickly, allowing the underlying code to be disassembled. Look at all the unofficial patches and mods for the popular PC games. There may be a whole treeful of low-lying graphics fruit here, particularly as games look for high-end video hardware. Now if the developers get beta versions of the games to test, they're going to be leaked ... and you can bet they're not watermarked.

There may be a whole treeful of low-lying graphics fruit here, particularly as games look for high-end video hardware.

I'm not sure I follow the "low lying graphics fruit" comment. How would this be helpful?

I'm not sure I follow the "low lying graphics fruit" comment. How would this be helpful?

I imagine that they would like to reuse the code, or at least get to understand how it interacts with the OS and hardware.

I imagine that they would like to reuse the code, or at least get to understand how it interacts with the OS and hardware.

"They" being who - developers? Pirates? I don't see how it'd be helpful for either group. At the low-level, the games are just linking to the OpenGL.framework anyway and reacting to the extensions OpenGL exposes.

"They" being who - developers? Pirates? I don't see how it'd be helpful for either group. At the low-level, the games are just linking to the OpenGL.framework anyway and reacting to the extensions OpenGL exposes.

You obviously aren't talking about the same thing.

I don't care who it is. Whomever "they" are might find some of that code useful.

Back in the bad old days when we did programming in assembly, low level code was the whole program. So, what are you talking about?

You obviously aren't talking about the same thing.

I freely admit that. What is everyone else talking about that I'm not?

I don't care who it is. Whomever "they" are might find some of that code useful.

 

Back in the bad old days when we did programming in assembly, low level code was the whole program. So, what are you talking about?

I'm not talking about anything specific - I'm still trying to figure out the statement I originally replied to - the talk of "low-lying graphics fruit", whatever that is. All I know is that "they" might find it useful, but I frankly don't understand how.

If we assume for the moment that we're talking about assembly code, I don't really grasp how having x86-native Mac games will help anyone vs. the current situation, since the action happens in OpenGL.framework anyway. If we're talking about high-level source code, it's really the same issue - the action still happens in the OpenGL.framework. Perhaps there's a third thing that everyone else is talking about but me. :-)

I'm not talking about anything specific - I'm still trying to figure out the statement I originally replied to - the talk of "low-lying graphics fruit", whatever that is. All I know is that "they" might find it useful, but I frankly don't understand how.

 

If we assume for the moment that we're talking about assembly code, I don't really grasp how having x86-native Mac games will help anyone vs. the current situation, since the action happens in OpenGL.framework anyway. If we're talking about high-level source code, it's really the same issue - the action still happens in the OpenGL.framework. Perhaps there's a third thing that everyone else is talking about but me. :-)

I'm not actually assuming that. "low-lying" could simply be "easy to understand".

I'm not actually assuming that. "low-lying" could simply be "easy to understand".

OK, since this thread has degenerated into nearly-meaningless ambiguities, let me stop asking questions and start making statements.

There is virtually nothing to be gained in terms of OSX on x86 analysis by having x86-native versions of games. This talk of making things easier to understand is nonsense, and there is no "low-lying graphics fruit" to be had here.

There's nothing you can figure out with a native game that you can't figure out right now. In fact, it'd be easier for you to figure things out now with regards to graphics and OpenGL simply because you already have a ton of example source code and can produce matching assembly code to go with it. With a binary-only native game, you do not. Furthermore, given that the only OpenGL drivers are currently for the i915 graphics chips, it's nearly impossible to draw a conclusion about OSX x86 OpenGL because we don't even know if the i915 hardware will ship in a Mac. It's gimped enough compared to what ATI and NVidia offer to make comparison difficult, if not impossible.

I'm not actually assuming that. "low-lying" could simply be "easy to understand".

I hope you know who you're talking to...

Well, after spending a couple of weeks away I was intrigued to return and find that my careless words had taken on a life of their own!

'Low-lying fruit' is an English metaphor for something that's easy to get rather than having to work hard for it.

What I meant (rather naively, I admit) was that *if* the games software was designed for high-end cards and *if* it accessed the video subsystems directly, it *might* provide a clue to how to overcome some of the problems we've seen with ATI and nVidia cards to date. I'm presuming that the games developers will have Apple's blessing and access to information we don't, and that they are less than scrupulous about disguising what they're doing. Any new information would be useful to the people working on getting graphics drivers to work. Yes, I know that we'd see a lot of standard calls but games are notorious for using undocumented functions and manipulating hardware directly in ways that bypass normal OS limitations. But I made a throw-away comment and I should have been more careful; I apologise if I caused confusion. I just happen to love disassembling code and was rather taken by the idea of pulling some game to bits to find out how it drove the video... Forgive me, I'm just a girl ... what do I know about anything?

I hope you know who you're talking to...

For those who don't know, Brad is well respected member of Aspyr's in house development team. I'd say he has a rather unique perspective on the situation.

if they are going to be bringing games to the intelMac's then i assuem they are going to support other sounds cards too. like the soundblaster audigy range ?

Looks like they (ATI or Apple) are spending some time on ATI drivers, at least. I know on a GMA950 system I have you can run HL2 and stuff barely (in windows, duh), but it sure gets creamed by anything else.

if they are going to be bringing games to the intelMac's then i assuem they are going to support other sounds cards too. like the soundblaster audigy range ?

Don't count on it. Apple and creative didn't have the best working relationship the first time they tried to bring the soundblaster line to the Mac.

things might change now that they are moving to intel cpu based boxes.

What I meant (rather naively, I admit) was that *if* the games software was designed for high-end cards and *if* it accessed the video subsystems directly, it *might* provide a clue to how to overcome some of the problems we've seen with ATI and nVidia cards to date.

OK, a couple of things here. First, all games talk to the hardware via OpenGL so unfortunately you won't find anything interesting there. Second, from what I understand, the graphics card companies (ATI and nVidia) found out at the same time as everyone else about the move to x86, so there were no native drivers in the initial seeds, nor any hint of them. I gather ATI has since gotten a strategy but from what I know, no one has been seeded with "Mac x86" ATI cards or drivers for the DTKs so there are no secrets to keep there. If someone knows how to get an ATI card going in the DTK, I'm super-interested. I see the article hinting at this, which I'm going to check out in a few seconds.

Yes, I know that we'd see a lot of standard calls but games are notorious for using undocumented functions and manipulating hardware directly in ways that bypass normal OS limitations.

I don't know that I've ever seen a Mac game use an undocumented call. As for the PC code we get, I don't recall seeing any undocumented stuff there either. I think this may have been the case in the 80's and 90's when performance was more critical, but honestly nothing much like that happens now, at least for PC and Mac games. Maybe consoles though...I don't know.

Thanks for putting me and everyone else straight, Brad. Appreciated. I'm still stuck in the 90s where games are concerned.

running Battlefield on my x86 pc, under OS X.... that'd be awesome!