views:

70

answers:

1

I've run into this problem several times before and wanted to hear what other's experience and advice is. Assume you have a working and stable but relatively small game engine that works on only one platform, and you want to port it to another platform.

The first step is obvious: you take the code, link it to the platforms libraries instead of the old ones, make necessary changes to the project or target build settings and then hit build. About five to twenty thousand errors appear. Of course there are a lot of duplicates but it immediately raises the question what the next steps should be?

How do you approach porting a game engine to another platform, or any platform-specific code that can't just be compiled on the other platform due to inherent changes in system and API design? How do you wade through all these error? How do you identify the parts that should be approached first?

In general: how should i approach porting existing source code?

I'm looking for general advice on how to approach a source code port. Assume the programming language and compiler are the same on both platforms, so it's mostly API changes.

+3  A: 

A textbook answer (perhaps) might be wrapping all of your platform-specific calls and using these wrapper functions throughout your code instead of the platform-specific. This way, if you can match the methods you use one-to-one on both platforms (easier said than done, maybe) then you can switch out which platform-specific function is called with your wrapper functions, and not change the rest of the logic in your code.

Say you have:

void RenderBadGuy(int badGuyID)
{
    // Windows-specific bad-guy rendering code here
}

For now you can just write ("G_" is for generic)

void G_RenderBadGuy(int badGuyID)
{
    RenderBadGuy(badGuyID);
}

This adds a small amount of overhead to your engine, but this shouldn't break things as you have them (just an extra function call).

Now, every place you use RenderBadGuy, just use G_RenderBadGuy. Rinse and repeat for all of your methods, and now later you can switch out your code to something like

void G_RenderBadGuy(int badGuyID)
{
    // now we're rendering on a Mac
    RenderBadGuy_Mac(badGuyID);
}

and then your main engine wouldn't change.

You probably can do this a lot nicer and more generically than this (pointers to functions, I don't know) but that's the idea.

Or, you could do a Java-like thing and have your library talk with a module that in turn knows the specifics of your platform. Just develop different modules (like VMs) for each platform, and you only develop your library once.

John at CashCommons
i know that's the right way to do it if you build a game engine, but what if the game engine already exists and has platform-specific calls all over the place? Could still be a good idea, then i'd end up with a bunch of void functions that i can later fill with actual code once the code compiles free of errors, is that what you meant?
GamingHorror
Edited my response to clarify.
John at CashCommons
I think it's easier to simply comment out the "windows-specific" stuff in RenderBadGuy, for one it won't compile on the target platform anyway and then i wouldn't have to change the name of the functions. The two ports are unlikely to be developed in parallel much. My main concern is how to get it running on the new platform in the first place. But thanks for the idea it got me thinking!
GamingHorror