Sign in to follow this  
I_Smell_Tuna

Porting between OSes

Recommended Posts

I want to develop a cross-platform video game. I will be developing it with C++ and OpenGL and I want to develop it for Mac, Windows, and Linux. When developing, the only changes that I can think of would be a recompiling on the respective system, and change how the input gets to the game logic. What else might I have to consider?

Share this post


Link to post
Share on other sites
Just don't bother - wait until you've got the game almost complete before trying to port it. Maintaining portability during development will be an annoyance, the game will be hard enough already.

Of course you should keep in mind the platform availability of any library you choose to use, but aside from that, proceed with the development on your chosen development platform and ignore the others until you're almost complete (for example, you want to show prototypes on those systems).

Mark

Share this post


Link to post
Share on other sites
It are the small differences, that create the big problems.

Using a platform independent API like SDL is the first step.

But also think about your C++ code. Do not use 'special' features of your compiler.
Do not use #pragma preprocessor directives.
Think about your data types, would they work for 64 bit systems as well ? (Also read about LP32, ILP32, LP64, ILP64, etc.)
Take care of data types like size_t, caddr_t or ptrdiff_t.
Think about filenames, when loading data files.

Share this post


Link to post
Share on other sites
Clanlib is another great library for cross platform stuff. It supports opengl and sdl and provides wrappers for display, networking, system timer, file io, ect.

www.clanlib.org

Share this post


Link to post
Share on other sites
Thinking about the actual code as you write it will save you some time, if possible use two compilers during development - Dev-C++ or Code::Blocks are both free IDEs which could be used.

Using a Windows port of GCC will highlight some potential code portability problems early on so you avoid becoming dependant on one particular compiler's features, especially since GCC seems to be the compiler of choice amongst most non-win32 platforms out there.

As ppl have mentioned, stick to portable libraries which exist for each of your target platforms. Then once the game is in a mature enough state on your main platform then you could start working on porting it to the other platforms but wait until you have something significant enough to warrant the effort, because chances are it not going to be a quick "copy the source, build, finished" and may require some tweaking/changing to get a successful build running.

Share this post


Link to post
Share on other sites
Yeah as others have mentioned, the most important bit is to be careful that you're using only libraries and compiler features that are common to all platforms.

There are only three other real things that you should know about developing cross-platform I think:

1) Maintaining makefiles and project files can be error-prone... changing the file list or compiler options in one won't propograte to the other. Either be very careful with this (read: make notes when you change stuff!) or try to automate this somewhat with scripting... potentially try to use a makefile system even on Windows, although then you lose some of the utility of a nice IDE.

2) Big vs. Small endian issues! If anything will be a major annoyance later, it'll be this. Since you're planning on writing software for the Mac, you have to be extra careful whenever you read/write files, or even do certain bitwise manipulations. Just realize that this is a problem up front and be prepared to write several versions of low-level file loading/parsing code. You must also test it thoroughly on all platforms that you plan to target - don't assume that it will work :)

3) If you're changing compilers between platforms, I guarantee that you'll encounter your share of different errors on different compilers. Usually BOTH (or all) compilers are correct, and the other just miss potential errors/warnings. I find that between GCC and VC++ you can catch *pretty* much everything, but very frequently will one catch something that the other doesn't. Initially I thought it was maining GCC catching stuff that slipped by VC++ but after some experience I think it's about equal. The moral of the story is that no compiler is perfect, and thus some quirks that may work on one will probably not work on another.

Good luck!

Share this post


Link to post
Share on other sites
today due to cross platform awareness your worries as opposed to during the past are not as great.

as long as you don't implement anything too fancy (like inline assembly or compiler directives) and use an api like SDL you should be fine.

good luck.

Share this post


Link to post
Share on other sites
Quote:
Original post by AndyTX
Yeah as others have mentioned, the most important bit is to be careful that you're using only libraries and compiler features that are common to all platforms.

There are only three other real things that you should know about developing cross-platform I think:

1) Maintaining makefiles and project files can be error-prone... changing the file list or compiler options in one won't propograte to the other. Either be very careful with this (read: make notes when you change stuff!) or try to automate this somewhat with scripting... potentially try to use a makefile system even on Windows, although then you lose some of the utility of a nice IDE.

There are alternatives to the normal make, like cmake, qmake, scons or jam. Having some target platforms in mind should narrow the list of choices enough.
BTW it's also possible to have a nice IDE while using a makefile system. I'm using Eclipse+CDT and MinGW/DJGPP/GCC as cross-platform IDE for windows/linux.
Eclipse is capable of generating the makefiles by itself (in managed mode), or to use a user-defined makefile for building.
Quote:


2) Big vs. Small endian issues! If anything will be a major annoyance later, it'll be this. Since you're planning on writing software for the Mac, you have to be extra careful whenever you read/write files, or even do certain bitwise manipulations. Just realize that this is a problem up front and be prepared to write several versions of low-level file loading/parsing code. You must also test it thoroughly on all platforms that you plan to target - don't assume that it will work :)

Correct!
But not just file I/O makes problems. The endianess also affects networking code.
Quote:


3) If you're changing compilers between platforms, I guarantee that you'll encounter your share of different errors on different compilers. Usually BOTH (or all) compilers are correct, and the other just miss potential errors/warnings. I find that between GCC and VC++ you can catch *pretty* much everything, but very frequently will one catch something that the other doesn't. Initially I thought it was maining GCC catching stuff that slipped by VC++ but after some experience I think it's about equal. The moral of the story is that no compiler is perfect, and thus some quirks that may work on one will probably not work on another.

Good luck!

Maybe a look into boost's regression tests may give you some idea:
http://engineering.meta-comm.com/boost-regression/1_32_0/developer/summary.html

Another thing that I want to add is multithreaded code. When changing from a multithreaded single cpu system to a system with multiple cpus, a program may behave differently (it may possibly crash while the single cpu system never would). Also thread priorities or the scheduling strategy of the OS may affect performance. Also synchronising between multiple threads may be platform dependent (or find a library that can do it on all your target platforms).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this