SDL for RISC OS
Neil White
Please note that before trying to compile any examples you will need the Castle 32bit SharedCLibrary installed on your computer.
I think I just about covered all I can with regard to SDL related libraries in previous issues, so this time I have chosen to give a introduction to the "joy" that is porting SDL apps. As you can see the word "joy" is in quotes because while a lot of developers will claim their program will be cross compatible in most cases they will have stuck in some Windows specific functions or use a library that isn't available under RISC OS. That said most programs originally written for Linux can be coped with because of the excellent Unix Lib, which allows developers to use most common functions found in Linux and Unix code. So with a little bit of luck a Linux SDL app can be ported with a few minor tweaks to the source code.
The example I have chosen to port is a simple ballfield demo. This contains two c files and a h file (header file).
Porting the Ballfield demo
The first job is to separate the garbage from the code. A large number of Linux apps will come with Linux autoconfigure related files that detect what Linux system you use and where all your files are. These don't relate to us in RISC OS land, so the first job is to delete everything except the c, h and any copyright or readme files that may be necessary.
The second step is to make the files RISC OS GCC friendly. To do this they need to be separated into directorys c and h removing any trailing .c's ( /c's in RISC OS ). As you probably know under RISC OS C code is stored in directories called "c" and "h". Under most other operating systems the files are stored in one directory with extensions on the end of each file to tell the compiler what they are. These two pictures might make it clearer.
This is the directory containing the original Linux source code.
This is the same code tidied up for RISC OS.
As you can see every file that had a "/c" on the end has gone in the "c" directory. Everything that had a "/h" on the end has gone in the "h" directory. Having tidied up the files we are just about ready to go.
The next job is to get a makefile to compile the code for us. Usually I just drag another one across from an existing SDL app and add the file names which we want GCC to compile. If you look in the makefile you will see all the files to be compiled, remembering that to RISC OS GCC main.c is actually $.c.main. As I have said in previous articles, I honestly believe no-one on the planet actually knows everything makefiles are capable of. Basically we need to tell the compiler to compile the separate source files and tell it what other files they need. Then they are all whisked together to a binary executable with some kinda GCC magic. (read the disclaimer from my first article).
Compiling
Now the files have been added to the makefile the nest step is to go head and try to compile.
On the first attempt you can expect to get a pile of SDL functions that haven't been found. This is because the "#include SDL.h" in the original source is not correct. It needs to be "#include <SDL/SDL.h>".
So once all the references to the source files have been changed the program should compile. We now have a potentially working binary. However all may not yet be well. The code can't find the graphics files unless the current directory in RISC OS is set to the working directory.
So you need to delve back into the code and alter each line where it loads a file "balls.png" to "<rwsdlex5$dir>/balls.png".
The path "<rwsldex5$dir>" is set in the !Run file. I appreciate that some might consider this to be a slightly slack way of doing it, but it works. Looking at my previous examples, they use a makefile definition of a 'DATA_PREFIX' which then, in the code, uses anything defined as 'DATA_PREFIX' to prefix the data files required. This ensures that they are being loaded from the correct directory on the users system, keeping the code more cross compatible.
If you were to try to compile the modified source on a Linux box the Linux filer would complain. This is because it would not know what on earth <rwsdlex5$dir> meant. However if there was a 'DATA_PREFIX' this could be set to the Linux users home directory allowing the code to be compiled under both RISC OS and Linux.
Now the !RunImage file knows where to find all the graphics files and is ready to be put into an application structure and used as a self contained program, So after firstly moving files around and secondly bodging the source about a bit, I have successfully ported an SDL program to RISC OS. It might be a slightly pointless one, but it works and the time taken was under and hour. Given that it would probably take a couple of days to write this demo from scratch you can see the advantage of porting existing programs to RISC OS.
Neil White