GP2X (another) Question To Those With Devboards

[evening2005]

Hi,

I'm wondering whether you can say how much effort is required to port an SDL-based game which already runs on Linux (and Windows and Mac). The game is written in C++ and uses bog-standard SDL plus SDL_image and SDL_mixer.

The reason I ask is that I have a very simple sprite library which I have developed over the last couple of years and I plan to release it in the very near future. However, I want to know how much work I will need to do to it to make usable on the GP2X. I've ordered my GP2X, but obviously it will be a few weeks before it turns up.

Thanks for any help you can offer.

 

[woogal]

It should either be a simple recompile or limited effort to get SDL stuff usable on the gp2x, especially if it's your own work. SDL_Mixer isn't available on the gp2x, but you can compile it and static link your code against it. I think SDL_Image is already available (if you're happy using gcc 2.95). One area that may need extra work is the input, as the version of SDL supplied by GPH maps the stick as a load of buttons instead of an actual stick. I managed to get a very complex game running in only a couple of days and most of that time was spent messing with the makefile trying to get it to compile as a single exe instead of an exe with a few libs. Once it was running it then needed a few tweaks (and still needs a few more) to get everything just right, but it's not too hard. I was actually very suprised and pleased to see how easy it is to get a basic port working.

(Disclaimer - all of the above is talking about SDL apps, not SDL+GL+Fmod+lots of other libs that a lot of games often listed as using SDL also require)

 

[evening2005]

It should either be a simple recompile or limited effort to get SDL stuff usable on the gp2x, especially if it's your own work. SDL_Mixer isn't available on the gp2x, but you can compile it and static link your code against it. I think SDL_Image is already available (if you're happy using gcc 2.95). One area that may need extra work is the input, as the version of SDL supplied by GPH maps the stick as a load of buttons instead of an actual stick. I managed to get a very complex game running in only a couple of days and most of that time was spent messing with the makefile trying to get it to compile as a single exe instead of an exe with a few libs. Once it was running it then needed a few tweaks (and still needs a few more) to get everything just right, but it's not too hard. I was actually very suprised and pleased to see how easy it is to get a basic port working.

(Disclaimer - all of the above is talking about SDL apps, not SDL+GL+Fmod+lots of other libs that a lot of games often listed as using SDL also require)

​

Thanks for your fast reply. It's all my own stuff and the classes use only SDL and SDL_image. The game(s) tend to use SDL_mixer for sound and music. What version of GCC is supplied with the SDK? I didn't understand your comment about gcc 2.95. Are you saying that the pre-compiled libs are compiled with that version?

 

[woogal]

The SDK consists of gcc 2.95, and a load of libs compiled with that version of gcc. The idea is you're supposed to use that version of gcc and dynamically link your exe to the libs that are already on the gp2x. This is fine as long as you don't require a more up to date version of gcc for whatever reason (my reason is I need fast floating point support which only became available in gcc 3.4). If you move up to a more recent version of gcc you need to recompile the libs you need using the same gcc, and static link to them (pass the -static flag to gcc when you link), otherwise your app will just thrown up loads of errors about incompatible versions. The downside to this is your app will be bigger (but not too big really, as even some large stuff will only be around 2mb), but the benefit is you can use more recent versions of libs and gcc without having to mess around with the kernel and filesystem on the 2x.

 

[MiniMoose]

The SDK consists of gcc 2.95, and a load of libs compiled with that version of gcc. The idea is you're supposed to use that version of gcc and dynamically link your exe to the libs that are already on the gp2x. This is fine as long as you don't require a more up to date version of gcc for whatever reason (my reason is I need fast floating point support which only became available in gcc 3.4). If you move up to a more recent version of gcc you need to recompile the libs you need using the same gcc, and static link to them (pass the -static flag to gcc when you link), otherwise your app will just thrown up loads of errors about incompatible versions. The downside to this is your app will be bigger (but not too big really, as even some large stuff will only be around 2mb), but the benefit is you can use more recent versions of libs and gcc without having to mess around with the kernel and filesystem on the 2x.

​

Does this mean that the SDK comes with the GNU versions of the C and C++ standard libraries? Yeesh, that's going to be some code bloat. Just another reason to circumvent the Linux Kernel, write driver libs directly on the metal and use embedded C and C++ standard library implementations.

 

[Puck2099]

woogal, could you make available an example Makefile to compile a simple "Hello World", please?

As you said it's difficult to mess with the Makefile, it could help to some Spanish developers who are 'playing' coding with their test GP2X

Thanks a lot.