Game porting requirments

[Jake]

I want to go 100% cross platform with future games, but I am considering recoding my current game to be cross platform. What I want to know is how much work is going to be involved. I am using cocoa and Open GL with objective-c as a language. I will try to build a running list.

• Replace all NSStrings with char arrays
• Redo file paths from NSBundle to a data folder
• Get rid of any other cocoa references (I didn't use too many of them)
• Get SDL added to the program
• Redo cocoa windows with SDL Windows
• Redo cocoa input with SDL input (would also allow for joysticks later)

These following ones have questions attached
• Get GCC to compile windows code - Can I do this in XCode or will it be easy to set up DevC++ on my PC to do it?


Thanks, I think my next game will be good enough quality to sell equal amounts for the PC and Mac.

[OneSadCookie]

Careful with the strings, make sure you test your game in paths that contain foreign characters.

[hokan]

* Don't forget about byte order issues - for game saves, network messages and such ...
* Make sure that your code really conforms to the language standard or whatever works in multiple compilers if standard support is shaky.
* You might want to look into build tools, so that you can use the same build file to build for multiple platforms e.g. Autotools (to make configure-make-install style make code), SCons ...
* Also consider where game preferences and save files should be stored in the filesystem, this may differ between OSes and depend on if the OS is a single or multiuser OS.

[hokan]

It has also been mentioned on this site, that the default C random function, has poor randomness in Windows - I assume that this only applies if the Microsoft C complier / random lib is used.

[Jake]

Thanks, Byte order should not be a problem. Both compilers I plan on using are GCC so that should help some.

[Joseph Duchesne]

Amen to that decision Jake, it's not hard to build a game 100% cross platform if you have two networked computers, a Mac and a PC (I use VPC, but a real one is "better" for testing).

[Jake]

AHHH! I can't even get a SDL program to run in XCode without references to cocoa with the template. Does anyone have a very bare bones XCode project with only C or maybe C++ that they can email me?

[Josh]

AHHH! I can't even get a SDL program to run in XCode without references to cocoa with the template. Does anyone have a very bare bones XCode project with only C or maybe C++ that they can email me?
The Mac OS X implementation of SDL uses Cocoa. I'm not sure why that's a big deal, though...

[PowerMacX]

AHHH! I can't even get a SDL program to run in XCode without references to cocoa with the template. Does anyone have a very bare bones XCode project with only C or maybe C++ that they can email me?

At one point, during the earliest stages of Okugai's development, I wondered how hard would it be to port it to Windows, since I was using cross platform libraries after all: SDL, SDL_image & SDL_mixer.

It took me 20 min. to download the Windows versions of the libraries, install them (basically, put the headers in the right directory and the dll's in the project dir.) and create a simple test project in MS VisualC++.
The actual porting of Okugai took something like 15-25 minutes, most of it involving working around silly behaviors in Microsoft's compiler (16 bit rand(), no "for (int i=0;i<something;i++)", HORRIBLE fscanf, etc.). Oh, and another 5 minutes to download & install updated OpenGL drivers from NVidia's | ATI's site (otherwise you'll get 2FPS and wonder what's going on - I did ;) )

Just ignore the Cocoa file from the Xcode project: make a test SDL project in VC++ or Dev-C++, ("Draw a red triangle" or something like that), once that works, drop all your source files in it, hit build and start fixing/#ifdef-ing as necessary. You'll be surprised how fast you can get your game up & running :)

Edit: Not a template by any means, but vSpeed (www.wirelesshamster.com/developer.html#vspeed) uses C++,SDL,SDL_mixer,SDL_image & OpenGL.

[phydeaux]

The actual porting of Okugai took something like 15-25 minutes, most of it involving working around silly behaviors in Microsoft's compiler (16 bit rand(), no "for (int i=0;i<something;i++)", HORRIBLE fscanf, etc.). Oh, and another 5 minutes to download & install updated OpenGL drivers from NVidia's | ATI's site (otherwise you'll get 2FPS and wonder what's going on - I did ;) )


Another subtle point for why porting is a good idea is that you might catch more bugs- between my win and mac builds, I had some bug where I de-allocated memory before I was done with it, which I only caught on one of the platforms. So it's certainly a practice that can make your code more bulletproof as well.

[Jake]

Thanks for the great info, I am going to start fixing up the code in my spare time. I will post any milestones when they come.

[Jake]

I now have SDL working on my mac, I didn't realize those cocoa files were just backend setup files. I have a nice little circle demo my friend wrote working without any code changes.

Now I have one big question about using ObjectiveC on windows. I know the language is cross platform, but what about methods like alloc and dealloc? I think they are from NSObject which is part of Cocoa. Does anyone know if they are built into the language?

[Steven]

If you want to use Objective-C on the PC (Windows or Linux) your best bet is probably GNUstep (http://gnustep.org/)

It's an open-source reimplementation of the NEXTstep API (Foundation and AppKit)

It's still a bit marginal in its ease-of-use, but it does seem to work after much fiddling.

[Jake]

If you want to use Objective-C on the PC (Windows or Linux) your best bet is probably GNUstep (http://gnustep.org/)

It's an open-source reimplementation of the NEXTstep API (Foundation and AppKit)

It's still a bit marginal in its ease-of-use, but it does seem to work after much fiddling.


WOW!!! If that works as good as it sounds this will be awesome, I was fearing having to port all of my NSStrings and such (NSBundle still may be a problem but is easy to get around I think)

[Steven]

It works almost as well is it sounds :)
Give it a try!

[maaaaark]

I'll admit I didn't read all of the posts, but the thing that grabbed me was the char arrays. I'd keep UTF strings in mind.

[Duane]

i wouldn't use obj-c; I'm not sure how good gnustep's implementation is, not to mention that obj-c is much slower than c.

[Jake]

Its a little late to switch languages considering everything is programmed in objective C and cocoa. Of course I could reprogram everything but I am trying to find the easiest way.

[Duane]

if that's so, then (on your next game), switch to C.

[maaaaark]

he means C++ ;)


And you don't have to do a full switch. You can mix Obj-C/Cocoa & C++ easily.

[reubert]

Give it a try, yes... but don't get your hopes up quite that much... My experiences with GNUStep about a year ago were mostly miserable. :( Perhaps it has improved since then...

[ravuya]

Give it a try, yes... but don't get your hopes up quite that much... My experiences with GNUStep about a year ago were mostly miserable. :( Perhaps it has improved since then...

I gave it a run a couple weeks back, and I can personally tell you the packages for Ubuntu and such are utterly broken. Paths are blatantly wrong, Makefiles are missing (or the wrong version) and a lot of stuff just doesn't work for reasons not entirely apparent to you when building with gcc4.

Here's hoping that Objective-C will become more of a priority, I think the event system has a definite benefit for game programmers of all platforms and I'd rather not restrict my games solely to the Mac.

[Bachus]

i wouldn't use obj-c; I'm not sure how good gnustep's implementation is, not to mention that obj-c is much slower than c.

The speed impact of using Obj-C is negligible. Some of the Cocoa API is slow, but those parts can be avoided. And of course, anything that needs that last little bit of optimization can easily be written in C.

Portability is really the only reason to avoid using Obj-C. And eventually GNUstep will be good enough to use.

[Steven]

And that will be a day for celebration :)