Pre-build testing
As suggested here, it's a very good idea to start by compiling a 'test' program - since if that fails it's a waste of time trying to get crimson to build
One of the never ending issues with the Pi is (lack of) a 'real' Open GL driver (the Pi comes with OpenGL ES, a 'cut down' version of OpenGL with much of the graphics processing done by 'software emulation' i.e. in the slow CPU, rather than by the (100x faster) GPU. Currently (2017) there is a 'trial' OpenGL driover for the Pi B3 (only). The B3 has a quad-core 64bit CPU and this is totally different from thr Pi Zero. This means that the Pi Zero is 'stuck' with OpenGLES (or the Mesa software emulation of OpenGL) and likely to be (quite) slow, however since Crimson Fields is a relatively simple 'turn based' game (and not a modern "shoot 'em up") it may well be 'fast enough'. Due (no doubt) to the lack of real OpenGL support, it's reported that 'SDL_HWSURFACE' doesn't exist and 'SDL_DOUBLEBUFFER' causes problems, whilst 'SDL_SWSURFACE' (apparently) works OK. This means we will need to check what SDL functions CF source is 'calling' (and modify it as necessary). Further, running under X windows appears to work (although it seems that setting some specific Video Mode (width and height) still causes issues) so use 'SDL_GetVideoInfo()' to detect the current (i.e. working) settings and stick to that It is possible to run in CLI (console) but, apparently, only in 'composite video' mode (users report problems with HDMI mode). Even in composite video you are limited to using one of the default video modes - and you must cater for overscan. To get 640x480, you set framebuffer_width=784, framebuffer_height=638 and then launch X windwos. This gets you a 640x480 display screen (if you try to start SDL app. in 640x480 mode on the framebuffer before starting X it crashes the Pi) Whilst full screen 1280x1024 is 'possible', it's really, really slow under SDL (recomendation is don't try the 'tuxpaint' Test app. in anything bigger than 800x600) Finally, the (default) Pi video frame-buffer is 16bits/pixel. You can run 24bit RGB, however every rgb pixel will be 'converted' on the fly (and it's going to be seconds per frame, not frames per second :-) ) Both SDL_HWSURFACE and SDL_DOUBLEBUFFER (at 16bpp 'native') causes 'flickering', so you have to stick to 'SDL_SWSURFACE'
SDL is 'supposed' to work on a 'stand-alone' basis, i.e. without needing to run it on an X-Windows desktop - however reports suggest (at least initially) you might have more success if you always work from X desktop GUI (rather than from the console CLI)
You will need a USB Keyboard/Mouse (i.e. directly connected to the Pi). If you try to control the Pi from a PutTTY (SSH session), you will run into "segmentation fault" errors
Permissions issues
Needless to say, the 'pi' user has almost no access to anything (that's why you have to keep typing 'sudo' before almost every command). When you come to run your software .exe, it 'inherits' the access rights of the user ('pi') .. and immediately 'falls over' because 'pi' has no rights to access the 'frame buffer' (display) !
To get around this you can :-
run the .exe as a 'super user' (i.e. 'promote' pi to su by typing 'sudo su')
run the .exe whilst the X server GUI is running
or (the 'correct' solution) add the .exe user ('pi') to the permissions group "video"
What version do you have ?
Start by checking what version of SDL is included :-
dpkg -l | grep -i sdl | grep dev
For Crimson, on the PC, I was only able to 'build' with SDL 1.2.13 (or earlier) as 1.2.14 no loger supports the '--prefix' command (as used in the Crimson 'configure' scripts).
>As of Raspbian Aug 2012, SDL 1.2.15 was included. So your first step is likely to be to 'unload' whatever version of SDL you have and go find 2.1.13 (for the Pi zero). Then you have to compile all the SDL components (to see what a nightmare it was for the PC, go look at my Building CF on Windows page) WARNING - after this, if you make the mistake of using 'update', you can wave 'good bye' to the old (working) SDL and say 'hello' to some new (non-working) version ..
Next you need the 'missing' libs (SDL_ttf etc) :-
sudo apt-get install gcc build-essential libsdl-ttf2.0-dev
Next up, to complie some 'c' source eg. 'testsdl' in in the /programs/ folder , we use :-
sudo /programs/testsdl $ make
sudo gcc `sdl-config --cflags` `sdl-config --libs` -O2 -o sdltest main.cpp
If sdltest is C++ source, instead of g++ we can use gcc with the C++ libraries. To do this we add "-lstdc++" to the command line like so :-
gcc `sdl-config --cflags` `sdl-config --libs` -O2 -o sdltest main.cpp -lstdc++