[sadie]

Does anyone have info on how viable/easy it would be to port a PC game (Windows, DirectX) onto OS X (probably RAVE)? Even better, is anyone willing to volunteer? We think we'll get the rights to port this game, but without the skills to do it!

Drop me a line and I'll let you know a little more about it.

[Angus_D]

I didn't think RAVE was in OS X? I think it's OpenGL only.

You might like to talk to the OmniGroup guys about it, they've done some game porting before, but mainly classic to cocoa.

[gregomni]

Originally posted by Angus_D:
You might like to talk to the OmniGroup guys about it, they've done some game porting before, but mainly classic to cocoa.

Actually it turns out to be easier to port the original code (Windows) than to try to port something that has been modified who-knows-how by an earlier port (to Mac OS before X). So a lot of our porting is PC -> Cocoa.

[sadie]

I think it's OpenGL only

Ok, not RAVE. At least a standard is hopefully a working standard.

Actually it turns out to be easier to port the original code (Windows) than to try to port something that has been modified who-knows-how by an earlier port (to Mac OS before X). So a lot of our porting is PC -> Cocoa.

How hard is it, generally? I've never done 3D coding in my life (hence me running screaming for help here), but we have the rights to a Mac port and it seems a shame not to use them.

[gregomni]

Originally posted by sadie:
How hard is it, generally? I've never done 3D coding in my life (hence me running screaming for help here), but we have the rights to a Mac port and it seems a shame not to use them.

To be honest, I personally am not involved in our game ports at all. (Too busy on OmniWeb/OmniOutliner/OmniDictionary/etc.)

Tim Wood has led our ports. He gave a talk at GDC 2001 (Game Developers Conference) about porting to Mac OS X. The slides and example code is here: http://www.omnigroup.com/community/developer/gdc2001/

He's also got an article on the same topic coming out in next month's Game Developer magazine.

Hope those help...
-Greg

[wadesworld]

How hard is it, generally? I've never done 3D coding in my life (hence me running screaming for help here), but we have the rights to a Mac port and it seems a shame not to use them.

Porting a PC game which uses DirectX to OS X will require 4 things (in general terms):

1) Sound porting
2) Input device porting
3) 3D API porting
4) Endian conversions

Sound porting is very easy. OpenAL and DirectSound map *very* closely to each other, so converting DirectSound to OpenAL is trivial.

InputDevice porting in theory won't be that bad once Apple releases the HID Manager documentation and sample code (which is supposedly being worked on now).

As for Direct3D to OpenGL porting, I have to admit some ignorance. In theory, it wouldn't be that hard - the process would be somewhat akin to porting DirectSound to OpenAL (i.e. you replace a Direct3D call to transform a vertex with an OpenAL call to transform that same vertex.) But I'm unsure what kind of custom structures Direct3D uses for storing its geometry data and how those would map to OpenGL structures.

As for endian issues, you have to make sure that anything that the PC version reads from or stores in a data file that is larger than one byte, gets properly byte-swapped.

Wade

[sadie]

Originally posted by wadesworld:
As for endian issues, you have to make sure that anything that the PC version reads from or stores in a data file that is larger than one byte, gets properly byte-swapped.

???

[gregomni]

Originally posted by sadie:
???

You're going to be in big trouble if you don't know what endian issues are.

An integer in a 32-bit CPU (both Intel & PowerPC have 32-bit integer registers) takes up 4 bytes. Different CPU architectures have chosen different ways of interpreting those 4 bytes as a single number.

The Intel architecture stores the least significant byte at the lowest address (thus the number 255 would be stored in memory as FF 00 00 00). Little end first, or little-endian. The PowerPC architecture stores the most significant byte at the lowest address (that same number is stored in memory as 00 00 00 FF). Big end first, or big-endian.

(The name comes from Gulliver's Travels: the big and little endian parties debated over whether soft-boiled eggs should be opened at the big end or the little end.)

In any case, for any data read from or written to a file, or any information sent over a network, if any of it consists of multi-byte numbers (not just the 4 byte integers mentioned above, but also shorts that are just 2 bytes), you need to make sure that the bytes that make up the number are swapped to be in the correct order for whatever computer architecture you are running on.

[sadie]

I have some clue about big/little-endian stuff, but i'm more of an ambitious web coder than a games designer - hence my cry for help

Surely there are BSD / Darwin functions that take care of that for you? Presumably it'd affect every program the same, and it's not generally a programming issue. Why are games different?

(if i remember rightly, the big and little-endians made this issue into a huge war, with no very good reason )

[Angus_D]

It's a problem for lots of programs. And it's not exactly as simple as "fix_endianness programname"

It seems to affect games more than other programs, probably because they have to do lots of fast manipulation of low-level data, in interests of speed.