Porting Direct-X to PPC for XBOX2, and Mac hardware cary over thread.
Quote:
Originally posted by gregmightdothat
The difficulty in porting games, as far as I know, is mainly in the processor differences. For instance, x86 chips have horrible floating point units. (Actually, Intel's compiler compiles all floating point math to the vector unit). As such, lots of stuff is programmed using integer math, which is where x86 shines, and generally outperforms PPC chips. Then, these are converted to floating point numbers later on. This conversion is cheap on x86 hardware, but somewhat expensive on the Mac.
It's all small details like that which take up the tiniest of overhead in most programs, but for games speed is critical as some functions get called literally millions of times a second. Going through to change all of these would be as hard or harder than recoding the entire game from scratch, so, games will always run faster on their initial target platform.
Another problem is that most Windows machines are single processor, and aren't multithreaded. (Another another problem is that OpenGL isn't thread-safe, so you have to have all of your OpenGL calls in one thread to avoid crashes, but that's just an issue with OpenGL, not a porting issue.)
Finally, some really important code is either done in assembly, or at least programmed to work on the vector unit. Because Intel's vector unit is nothing like Altivec, this all has to be entirely recoded. And of course, because these routines are called so often, they have to be fairly extensively tested, too.
At least with the first and third issues, though, Cell is going to be a big help with games that are designed for the XBOX2/PS3 first and later ported to PCs/Macs. If Cell uses the Altivec instruction set, then the last bit will also be remedied on Mac ports, although personally I'm rooting for slightly richer instructions.
Originally posted by gregmightdothat
The difficulty in porting games, as far as I know, is mainly in the processor differences. For instance, x86 chips have horrible floating point units. (Actually, Intel's compiler compiles all floating point math to the vector unit). As such, lots of stuff is programmed using integer math, which is where x86 shines, and generally outperforms PPC chips. Then, these are converted to floating point numbers later on. This conversion is cheap on x86 hardware, but somewhat expensive on the Mac.
It's all small details like that which take up the tiniest of overhead in most programs, but for games speed is critical as some functions get called literally millions of times a second. Going through to change all of these would be as hard or harder than recoding the entire game from scratch, so, games will always run faster on their initial target platform.
Another problem is that most Windows machines are single processor, and aren't multithreaded. (Another another problem is that OpenGL isn't thread-safe, so you have to have all of your OpenGL calls in one thread to avoid crashes, but that's just an issue with OpenGL, not a porting issue.)
Finally, some really important code is either done in assembly, or at least programmed to work on the vector unit. Because Intel's vector unit is nothing like Altivec, this all has to be entirely recoded. And of course, because these routines are called so often, they have to be fairly extensively tested, too.
At least with the first and third issues, though, Cell is going to be a big help with games that are designed for the XBOX2/PS3 first and later ported to PCs/Macs. If Cell uses the Altivec instruction set, then the last bit will also be remedied on Mac ports, although personally I'm rooting for slightly richer instructions.
Quote:
Originally posted by wmf
The biggest problem in porting games is DirectX vs. OpenGL. The processor is minor in comparison.
Originally posted by wmf
The biggest problem in porting games is DirectX vs. OpenGL. The processor is minor in comparison.
Comments
Link to other hardware thread. LINK
Converting of DirectX to OpenGL code is the bare minimum for a port. When you first run that, you'll realize it's a very superficial port that needs lots of optimizations before it's ready to market.
It's not really all that hard though-nowadays most of the commands have a 1 on 1 correspondance between the two, so a simple regexp could take care of a good chunk of the work. The rest is mainly things like initialization or the few exceptions to that 1 on 1 thing, neither of which are particularly time consuming.
To make a good port, you DO need to take into account architecure differences between the Intel and Mac platforms. This isn't so important in 95% of software, but for games, it's crucial to at least optimize the most oft-called functions.
There are rumors that PS3 will use OpenGL.
Originally posted by gregmightdothat
Converting of DirectX to OpenGL code is fairly trivial. Nowadays most of the commands have a 1 on 1 correspondance between the two, so a simple regexp could take care of a good chunk of the work. The rest is mainly things like initialization or the few exceptions to that 1 on 1 thing, neither of which are particularly time consuming.
That's the bare minimum for a port. When you first run that, you'll realize it's a very superficial port that needs lots of optimizations before it's ready to market.
I take it from that comment you've never actually ported a commercial game.
Originally posted by gregmightdothat
(Edit: the switching over of the thread has me slightly confuddled, so this may not be worded quite right)
Converting of DirectX to OpenGL code is the bare minimum for a port. When you first run that, you'll realize it's a very superficial port that needs lots of optimizations before it's ready to market.
It's not really all that hard though-nowadays most of the commands have a 1 on 1 correspondance between the two, so a simple regexp could take care of a good chunk of the work. The rest is mainly things like initialization or the few exceptions to that 1 on 1 thing, neither of which are particularly time consuming.
To make a good port, you DO need to take into account architecure differences between the Intel and Mac platforms. This isn't so important in 95% of software, but for games, it's crucial to at least optimize the most oft-called functions.
Yes, and question #2. With the fact that wmf mentioned XNA which will be running on a PPC processor for XBOX2. With XNA/(newDirectX) already being on a PPC have any effect on porting it to the Mac, or make things any easier?
Originally posted by onlooker
Yes, and question #2. With the fact that wmf mentioned XNA which will be running on a PPC processor for XBOX2. With XNA/(newDirectX) already being on a PPC have any effect on porting it to the Mac, or make things any easier?
From what I've read it seems as though it could make porting easier, however, the PPC chips in the Xbox2 will have a different architecture from macs and also a PPC version of directx aka XNA would only be useful if Apple could use it on macs. Most likely is that the game would still have to be ported to opengl which makes life difficult, as we all know directx has set standards whilst opengl is open source and therefore it is left up to the game developers.
So in a small way it could make a difference in the performance of games
Originally posted by gregmightdothat
The difficulty in porting games, as far as I know, is mainly in the processor differences. For instance, x86 chips have horrible floating point units. (Actually, Intel's compiler compiles all floating point math to the vector unit). As such, lots of stuff is programmed using integer math, which is where x86 shines, and generally outperforms PPC chips. Then, these are converted to floating point numbers later on. This conversion is cheap on x86 hardware, but somewhat expensive on the Mac.
If such a basic mathematic foundation is different between the two APIs, then one must wonder what else (and on what level) must be fixed.
Originally posted by mattyj
we all know directx has set standards whilst opengl is open source and therefore it is left up to the game developers.
DirectX is controlled by Microsoft, although they do have a board that oversees its progress.
OpenGL is controlled by the OpenGL Architecture Review Board. It is not open source.
You're thinking of the implementations, not the standards. MS implements DirectX, and ships that implementation with every copy of Windows. The GPU vendors implement OpenGL in their drivers (for UNIX and Windows), with varying degrees of completeness and compliance and performance—especially at the consumer level.
Most Mac game porting houses have built up a DirectX-to-OpenGL library over the years, so that's not so much an issue for mature porting houses like Westlake. The #1 issue is money: Is it worth the extra trouble and risk of porting to sell another few thousand copies?
Think about how many threads there've been on this board alone where someone asking about Mac gaming was told to "get a PS2." Fine, so if I was a game developer, and I wanted to target Mac gamers, I'd port to PS2. Actually, I'd probably develop first for PS2. Port the game to XBox, and I'd have most Mac gamers covered.
Originally posted by Tuttle
I take it from that comment you've never actually ported a commercial game.
Sorry, you got the half-mucked up version. Wmf and I were talking about only semi-related things, and when I realized that, I went back to edit it so that it made sense.
Anyway, I'm repeating myself a bit here, but:
DirectX/XNA/whatever will never make it to the Mac platform (as Microsoft has no reason to), and it being on a PPC won't help Mac games any in and of itself.
However, if games are initially developed for the XBOX2, PS3, or Nintendo's next system, the code will likely already be optimized for the PPC and possibly Altivec architecture. Since these things are what's really hard to port, this means that games developed initially for consoles will port better to the Mac than to the PC. (Also note that Microsoft's current devkits for the XBOX2 are Power Mac G5's :P)
Of course, right now most games released for the Mac started on the PC first and then were later ported to consoles, and if things stay like that, then there won't be a huge difference.
In working on a completely unrelated probem, I found out that OpenGL uses right-handed matricies for 3D vertex manipulations, and DirectX uses left-handed ones.
If such a basic mathematic foundation is different between the two APIs, then one must wonder what else (and on what level) must be fixed.
Didn't know that, but all the matrix data can really easily be "transposed" beforehand, and it's not to hard to switch around a few functions to handle this.