Building ScummVM for the Caanoo

[surdules]

I managed to get ScummVM to build for the Caanoo, but when I execute the binary on my Caanoo, the graphics look screwed up. The initial GUI screen looks as though it's spreading the pixels over a larger "virtual" screen that doesn't fit on the Caanoo screen; so when I move the mouse around, I can see 4 ghost mouse pointers moving, etc. Also when I quit out of ScummVM to get back to the GPH main screen, it generates a random noise through the speakers.

Here's my environment:

- Windows XP
- Latest Cygwin (only base packages + make)
- Latest official GPH SDK (10.11.03) from fungp.co.kr
- Latest (trunk) ScummVM source
- Latest version of all dependencies (SDL, zlib, etc.)

First, I built SDL using the following variables and commands:

export PATH=/cygdrive/d/Dev/GPH_SDK/tools/cross-eabi/arm-gph-linux-gnueabi/bin:$PATH
export PATH=/cygdrive/d/Dev/GPH_SDK/tools/cross-eabi/bin:$PATH
export CXX=arm-gph-linux-gnueabi-g++
export CC=arm-gph-linux-gnueabi-gcc
export CXXFLAGS="-mcpu=arm926ej-s -mtune=arm926ej-s"
export CPPFLAGS=-I/cygdrive/d/Dev/GPH_SDK/tools/cross-eabi/include
export LDFLAGS=-L/cygdrive/d/Dev/GPH_SDK/tools/cross-eabi/lib
export ASFLAGS=-mfloat-abi=soft

./configure \
--host=arm-gph-linux-gnueabi \
--target=arm-gph-linux-gnueabi \
--build=i686 \
--enable-static \
--enable-shared=no \
--enable-pthreads \
--enable-pthread-sem \
--enable-threads \
--disable-video-fbcon \
--disable-video-directfb \
--disable-video-x11 \
--disable-alsa \
--disable-arts \
--disable-esd \
--disable-pulseaudio \
--enable-video

Then, I built ScummVM using the same environment variables above, and the supplied scripts in scummvm\backends\platform\gph\caanoo.

Is this an SDL problem, in other words do I need a special version of the SDL library that's modified to support the Caanoo?

Also, I think I built ScummVM statically linked against SDL, but I'm not sure; could this be a conflict between my ScummVM binary and a different version of the dynamic SDL library that's already on the Caanoo?

Thanks for any pointers. When I'm done with this, I intend to write-up a Wiki page on it and share it with the community.

Razvan.

[surdules]

I figured it out: the problem is that the official SDL distribution does not support the Caanoo. Instead, I used the unofficial Caanoo port of SDL, and that works.

I'll post detailed instructions about this on the Wiki soon.

Razvan.

[DJWillis]

Hi,

Before you post anything to the WiKi can you make sure your building what your think your building .

You will need to tweak the configure to add support for GPH's toolchain and detecting/using the GPH backend, I suspect your just building the main SDL codebase at the moment. Nothing wrong with that but you will be missing a fair bit of functionality.

For what it is worth the ScummVM Caanoo backend pre-dates the release of the GPH Caanoo SDK (well that's what they call it ). I found when building with the GPH SDK/Toolchain I encountered lots of issues ranging from strange alignment type issues to outright crashes, as it is rather hard to rebuild or investigate the providence of the GPH SDK I used a toolchain I pulled together using libraries from the device or ones compiled within the toolchain.

I have this SDK/toolchain package for Linux if your interested. In theory you could just add the libs into a Windows build of ARM EABI GCC but I can't say I will go out of my way to support GCC cross-compile builds on Windows as it always opens a world of pain for new users.

Also, please try and avoid static linking if you can, there is really no need on the Wiz/Caanoo and static linking of the support libs without good reasons just proliferates the mess that the GP2X got into .

There should be nothing wrong with the SDL in the GPH SDK or on the device in the context of ScummVM . The releases I have done are all dynamic linking the on-device SDL without any problems.

[surdules]

Before you post anything to the WiKi can you make sure your building what your think your building Wink.

Sure, the reason why I want to put stuff on the Wiki is that the Caanoo build is very complex and there is almost no information on it, so I had to figure it out myself. I'd be happy to discuss it further in the forums (before posting on the Wiki), and then feel freed to edit the Wiki to correct any errors I might make.

You will need to tweak the configure to add support for GPH's toolchain and detecting/using the GPH backend, I suspect your just building the main SDL codebase at the moment. Nothing wrong with that but you will be missing a fair bit of functionality.

I edited/used the scripts under backends/platform/gph/caanoo/, in particular config.sh, build.sh, and bundle.sh Let me know if these are not the right scripts to use.

For what it is worth the ScummVM Caanoo backend pre-dates the release of the GPH Caanoo SDK (well that's what they call it Wink). I found when building with the GPH SDK/Toolchain I encountered lots of issues ranging from strange alignment type issues to outright crashes, as it is rather hard to rebuild or investigate the providence of the GPH SDK I used a toolchain I pulled together using libraries from the device or ones compiled within the toolchain.

I used the official GPH SDK for Windows. The build went without problems, I didn't have to change the source in any way, just the build scripts.

The executable seems to run fine on my Caanoo, I only tried a few of the engines, but I can do more exhaustive testing to see if I run into issues. If possible, would be nice to use the standard/official tools, as it seems a lot easier to setup that kind of environment for someone starting out from scratch.

I have this SDK/toolchain package for Linux if your interested. In theory you could just add the libs into a Windows build of ARM EABI GCC but I can't say I will go out of my way to support GCC cross-compile builds on Windows as it always opens a world of pain for new users.

I was thinking of installing Linux (just to use the Linux SDK/toolchain), but I thought I'd try out the Windows tools first. To my surprise, it worked, and with little pain! If, after further testing, it looks like the Windows SDK/toolchain works, doesn't that seem like a reasonable (and possibly easier) way to go?

Also, please try and avoid static linking if you can, there is really no need on the Wiz/Caanoo and static linking of the support libs without good reasons just proliferates the mess that the GP2X got into Wink.

This makes sense, can you tell me more about this? In particular, it seems unavoidable to statically link against libzlib, libpng, libmad, and libtremor (they don't generate dynamic libs, AFAIK). The only library that seems to produce a shared object is libSDL. Is that accurate?

There should be nothing wrong with the SDL in the GPH SDK or on the device in the context of ScummVM Smile. The releases I have done are all dynamic linking the on-device SDL without any problems.

That's good to know. Just to clarify, the correct SDL to use is the "unofficial" one from openhandhelds.org, and you're just suggesting I use a dynamic lib as opposed to a static lib? AFAIR, the official 1.2.0 build for ScummVM does not come with a shared lib for SDL, but I'm not 100% sure. If the official build does use a shared SDL lib, how is it installed on the Caanoo, where does it go?

Razvan.

[DJWillis]

Hi,

I read through your reply (and the guide you linked me to, thanks, it’s a nice guide just for a bad toolchain (IMHO ).

Don’t take any of my responses as in any way disparaging, that’s not my intention.

Before you post anything to the WiKi can you make sure your building what your think your building Wink.

Sure, the reason why I want to put stuff on the Wiki is that the Caanoo build is very complex and there is almost no information on it, so I had to figure it out myself. I'd be happy to discuss it further in the forums (before posting on the Wiki), and then feel freed to edit the Wiki to correct any errors I might make.

Ok, so the documentation is lacking (I guess that is always the way) but building ScummVM for the Caanoo (from a Linux host with a well setup cross-compiler) is actually very simple. The Caanoo port has only been released with the 1.2.0 version of ScummVM so is hardly mature .

I really worry about instructions on the WiKi for a toolchian that in my view builds bad code and is esoteric in its setup.

I am happy to put the instructions for the toolchain I use (but that is Linux based) and of course people are welcome to adapt those instructions to suit but I also feel it is fair to view the WiKi as 'official' instructions and as the backend author I am not prepared to support the GPH toolchain/SDK.

Also, please try and avoid static linking if you can, there is really no need on the Wiz/Caanoo and static linking of the support libs without good reasons just proliferates the mess that the GP2X got into Wink
This makes sense, can you tell me more about this? In particular, it seems unavoidable to statically link against libzlib, libpng, libmad, and libtremor (they don't generate dynamic libs, AFAIK). The only library that seems to produce a shared object is libSDL. Is that accurate?

You also seem to want to static link regardless and I can't see the reasoning behind this, it seems to come about because of the broken/non standard nature of the GPH toolchain/SDK, I can’t think of any other reason.

All of the libs used by ScummVM have dynamic (.so) variants in the toolchain and all the libs are also sat on the device, there is absolutely no reason to static link on the Wiz in the context of ScummVM and the libraries it currently uses (and even with things like Theora that may be on the cards it would be preferable to just ship a .so with the binary or offer a way to install it to the NAND then static link .

There should be nothing wrong with the SDL in the GPH SDK or on the device in the context of ScummVM Smile. The releases I have done are all dynamic linking the on-device SDL without any problems.

That's good to know. Just to clarify, the correct SDL to use is the "unofficial" one from openhandhelds.org, and you're just suggesting I use a dynamic lib as opposed to a static lib? AFAIR, the official 1.2.0 build for ScummVM does not come with a shared lib for SDL, but I'm not 100% sure. If the official build does use a shared SDL lib, how is it installed on the Caanoo, where does it go?

As for SDL, yep, there is a nice .so sat on the Caanoo, why would I need to package it with ScummVM either dynamically or statically?

You don’t bundle libraries with an application if every device in existence has just what you need installed on the NAND out of the factory .

The unofficial SDL you link to is just a handfull of changes to the SDL source (enabling double buffering being a big one) and none of the changes are specifically beneficial to ScummVM so the NAND version is just fine for what it is used for.

Regards,

John

[surdules]

Hi,

Thanks for the information! I don't take any of this as disparaging, I'm just not very familiar with the Caanoo, so I'm trying to learn more.

You also seem to want to static link regardless and I can't see the reasoning behind this, it seems to come about because of the broken/non standard nature of the GPH toolchain/SDK, I can’t think of any other reason. [...] You don’t bundle libraries with an application if every device in existence has just what you need installed on the NAND out of the factory.

I didn't realize is that the Caanoo comes with these specific shared libraries (like PNG, SDL, ZLIB) already installed! In that case it totally makes sense to link dynamically, as well as use those same exact device libraries in the SDK toolchain to avoid bugs. I think you mentioned this already earlier -- now it makes sense.

I am happy to put the instructions for the toolchain I use (but that is Linux based) and of course people are welcome to adapt those instructions to suit but I also feel it is fair to view the WiKi as 'official' instructions and as the backend author I am not prepared to support the GPH toolchain/SDK.

That's fair. If you can put up those instructions/binaries somewhere, I also setup Linux, so I'd be happy to give it a try and see if I can get it to work. I'd also still like to try to get the build to work on Windows + Cygwin, but that's a secondary priority.

A couple of additional points:

1. It seems to me from what you're saying that the shared libraries posted with the official GPH SDKs do not match the shared libraries installed on the device. Is this true? If so, I find this pretty surprising, why would GPH publish an SDK with different/incompatible libs?

1a. Part of the reason why I was compiling everything statically initially is also to avoid potential conflicts with any existing libs on the device. But if I can get the exact same libs on the device, then it makes sense to compile dynamically.

1b. It seems that, in order to get the libraries from the Caanoo to link against, I need USB net or USB serial. Is this accurate?

2. The toolchain seems to consist of a cross-compiler + the libraries above. Did you have to do anything special to build the cross-compiler, or is it fine to use the cross-compiler published on openhandhelds.org + the official libraries?

Thanks!

Razvan.

[surdules]

BTW, I just tried to compile ScummVM on Linux using the official GPH Linux SDK (from http://fungp.com/dv/ne2_l.asp). It behaves very similarly to the Windows build, meaning, the package builds, some engines work on some games, but it's overall quite flaky. I built everything using dynamic linking against the libraries supplied with the GPH SDK itself.

You're right that there is something rather wrong with the official Windows and Linux GPH SDKs.

If you can post binaries/instructions for how you assembled your toolchain, I'd love to give it a try.

Thanks!

Razvan.

[DJWillis]

Hi Razvan,

Sorry, things have been more than a little manic of late.

I'll do up some instructions for the WiKi and upload tarballs of the toolchain etc. over the next few days.

In fairness TRUNK for the GPH devices still needs some more TLC following the OpenGL merge recently, just not had the time to do it .

[surdules]

Hi John,

No problem about the delay, I know what you mean about hectic. :-/ If you get a chance to update the instructions and upload the tarballs, I'd love to give them a try sometime.

Cheers,

Razvan.