Quote:Original post by MatrixCubed
Hi all,

Currently, I am attempting to port my game engine to Linux. I'm going to post some thoughts here, and potentially some questions, as I have been working on this game engine for roughly 10 months, and am porting it in the early stages of its development to ensure that I don't have a larger mountain to climb down the road. :) Thus far I've been following cross-platform coding practises, and selecting libraries which have cross-platform compatibility.

I've been testing a few different IDEs (Anjuta, KDevelop3, Code::Blocks), and I have been facing some serious adversity. My main problem is library support; I'm using MySQL-client, SDL, SDL_Image, libpng, zlib, Raknet, STL, and potentially a few other libraries I can't think of at the moment. The IDEs above have been less than newbie-friendly!

It seems the best thing I can do at this point in time, is stick with an IDE which has a good interface, (e.g. Kate for example) but compile the code using a custom makefile. Problem here is, it seems a daunting task to find the different linker options necessary for the libraries I'm using. It also seems like a real pain to have to edit the makefile anytime a new class or library is added to the project; it just seems like there must be a better way!

Can anyone suggest some pointers or online references they found particularly helpful, related to this topic?

Best regards,

Step one: Complete the engine on ONE platform and ONE game. This ensures you will get something done. Most people fail to complete this step because they are paralyzed by wanting to keep things portable. Just use standard C++ and portable APIs (ie: not DirectX) and it will be mostly portable. If you actually design your app (GASP!) and keep the presentation and input separate from the logic, you'll be even better.

Step two: Use the engine for several games on ONE platform. This helps ensure that it is actually an engine, not just a one-game specific library. Most of the remaining people stop here.

Step three: Port the engine to one other platform. This will be less hard because you know what the pieces are, and hopefully you've keep porting in mind from day one. Make sure that the existing games can move over. Usually by this time you will have a following that will help you.

Step four: Repeat from step two for incremental number of platforms.

frob.

Quote:Original post by Vexorian
It seems to me he already finished the engine for other platform.

I was inferring that to not be true, based on these comments:

* am porting it in the early stages of its development
* potentially a few other libraries
* less than newbie-friendly
* anytime a new class or library is added

I still recommend making it complete on only one platform before you attempt to port it. Keep the goal of porting in mind, but don't kill your project in an attempt to get it portable.

In any event, the use of GNU Build Tools (automake, autoconf, and configure) along with make files are really the best way to go.

frob.

I believe Anjuta generates autotools files for you, there should be a way in there to add custom commands for the libraries you're using, I dont know what Raknet is, I am not sure if there is a predefined m4 macro for MySQL, STL comes standard with GCC, so no checks are necesary (unless you're compiling c++ code with gcc as oposed to g++, then you need to add the check for the stdc++ library), SDL_Image, libpng, zlib are pretty straight forward, they just require you to add a couple of lines to configure.in or configure.ac, like so, for SDL_image:



SDL itself provides a config script, so if you're compiling for just yourself, and you know you have the development libraries installed, add the lines:



again, to your configure.[in|ac] file.

I really recomend reading the autotools book though.

Quote:Original post by MatrixCubed
frob: I didn't ask for a treatise on game design theory, and I did not find your post informative; truthfully it was inflammatory and arrogant.
...
It make sense to me that, if any parts of the engine I am working on are not portable, now would be the best time to adjust what I am doing, as opposed to a year from now where I might end up recoding a sizeable chunk of the application.
...
I'm really not sure what the deal is with Code::Blocks. I'm running it on Kubuntu 5.10, but the error I'm getting is poorly documented. Since this app seems fairly fledgeling, I would rather avoid its inevitable growing pains, and find a decent workaround. :)

I'm sorry you saw it that way. Allow me to clarify.

Over the past 15 years, I've seen many projects die because the authors wanted to make something portable. Many wonderful projects have died prematurely because the authors were attempting to make something portable up front rather than completing the project.

In my experience, a careful design is the most critical step to ensure portability. Design it, implement it fully on one platform. Make it work well on one platform, improve the design, THEN port. Yes, it is part of "a treatise on game design theory". I mentioned it in the earlier post as a reminder. Choosing to use or disregard the "theory" -- or what I would call the collective experience developed over the entire course of game development history -- is your choice.

The fact that you selected portable libraries to begin with shows that you have taken a bit of that "game design theory" to heart.

Whenever your port an engine, you are going to end up recoding a sizable chunk of the libraries. That's just a fact you are going to have to face. It is much easier to do that after it is complete on one platform. At that point you know what is expected of each module, and understand how they work together.

Porting before it's complete means you're gonig to have to maintain several versions of code in development. If you decide to rewrite a big chunk of code, you'll not only have to do it for one platform, but several. If you decide that a portion of the code won't be used, or to redesign a module of the engine because you did it wrong the first time, you'll also have to do that on several platforms. That is an unneccesary waste of time.

I'll end this "treatise on game design theory" now.

frob.

I have to agree with Frob on this. Assuming decently good software design and not using any OS-specific APIs, porting to Linux after-the-fact is not going to be more difficult than porting doing so before-the-fact.

For a project with complex dependencies such as yours I suggest you avoid IDEs' native build systems in the long run, since they are quite rigid and hardly ever fully compatible with each other. Use a portable, scriptable and adaptable build system like scons or the autotools. If you decide to take frob's and Sneftel's advice and do the porting later then migrating to a portable build system now will probably not give you any immediate benefit.

My probably not so useful advice: don't make porting a number one priority at this time but do spend a little time on it if you can. If you are anything like me you will sometimes have moments when you don't feel like doing any serious coding but still want to get something useful done. Use such times hack together autotools files for your project and try to get it to compile. It will be frustrating initially but remember that you are not in any kind of a hurry.


If you happen to release your work as open source and your code is well designed then you might very well just find a Linux patch for it in your inbox one morning.