Installing SDL

Now that we have our basic tools installed, it’s time to put them to use, and we are going to create a simple CMake build system to support our development efforts. Of course, we need to be able to test it, so we will be making a simple SDL program as well. Thus we must now install SDL, the Simple Directmedia Layer and I have decided to separate SDL installation into its own article rather than clutter the CMake article with it. Once we have this done we can move on to our CMake setup.

The Simple DirectMedia Layer is a cross-platform library to let you easily access the keyboard, mouse, joystick, audio, and video systems of your computer. We will be using SDL principally for its windowing and event handling functions. SDL has a simplified syntax for creating windows and handling events that makes creating GUI applications much easier than they normally are when using standard Windows and Linux methods. By letting SDL handle this for us, we not only will have an easier time writing code, but we will also be able to use the same window and event handling code on all our target platforms.

We will be using the latest development version of SDL, 1.3, taking it directly from the current source tree. We could use SDL 1.2 for our early efforts, but as soon as we add OpenGL into the mix then we must use SDL 1.3 because version 1.2 only supports OpenGL 1.x and 2.x, and we will need to have support for more recent versions of OpenGL.

First, decide where you want to put the SDL source code and build the library. On my Linux system I put it in /home/eris/gamedev/deps/sdl and on my Windows system it’s in C:\gamedev\deps\sdl. The location is not that important, but I do like to follow a couple of rules. First, keep each library or program’s source code in its own directory. Second, build the software in a different directory, which means that the binary files created by the compiler do not get mixed up with the source files. This makes it much easier to keep multiple sets of binary files on hand, which is about to become very important when we build our first program that has both Linux and Windows binaries built for it. It also makes it easier on us if we want to experiment with using different versions of the same library. (For example, you might want to use SDL 1.2 for software your release, but still have SDL 1.3 available for testing.)

This script should install SDL automatically for you, assuming that you want it put in the same directory that I am using. It runs on Linux and also in the MSYS shell on Windows.


#!/bin/bash

set -x
set -e

if [ "$OSTYPE" = "linux-gnu" ] ; then
TopDir="$HOME"
elif [ "$OSTYPE" = "msys" ] ; then
TopDir="/c"
else
echo "Unknown system."
exit 1
fi

cd "$TopDir"
mkdir -p gamedev/deps/sdl/SDL-build
cd gamedev/deps/sdl

hg clone http://hg.libsdl.org/SDL
cd SDL

./autogen.sh
Options="--enable-ssemath --enable-sse2"
./configure --prefix="$TopDir/gamedev/deps/sdl/SDL-build/" $Options
make
make install

Download this script

And this is the first example of why I chose to install MSYS on Windows, and not just the MinGW compiler by itself. With MSYS available I can use nearly the exact same commands to install SDL on Windows as I do on Linux. This kind of cross-platform tool compatibility is what I really want, so that the process of developing games can be as easy as possible. There’s already enough complexity in programming as it is. Let’s not add more by using different toolchains to accomplish the same goals.

There are a few things to comment on, here.

Notice the directory structure: sdl, sdl/SDL, and sdl/SDL-build. The first one, sdl, is just a folder to to hold all things SDL related. Later on we will add some other subdirectories to it for various SDL add-on libraries, such as SDL_net and SDL_mixer.

The sdl/SDL directory is the one we pulled from the libsdl.org website and it contains the official source code for the library. Nothing else goes here, and apart from files modified by the configure script we will not be modifying anything in here.

The sdl/SDL-build directory is where we actually build the library. The DLL, lib, and include files are here, so this directory is one that we will be referencing in our own projects.

As for the configure options, we mostly accept the defaults (you can see all available options run running ./configure --help) but we do specify --enable-ssemath and --enable-sse2 to turn on support for the SSE floating point instructions, which all modern processors support.

For the Windows build we also specify --disable-stdio-redirect. By default, programs that use SDL on Windows have their standard C/C++ text output redirected to the files stdout.txt and stderr.txt. I suppose this is done because most Windows programs are run by clicking on an icon rather than running them from a command prompt, and without the redirection all the output would be lost. But then again, the same is true for graphical programs on Linux and the i/o is not redirected by default for them. Personally, I would rather have the i/o handled normally so that I can run from the command line to see the output, or just click on icon to ignore it. If you would rather keep the redirection, just remove the line from the script above that says if [ "$OSTYPE" = "msys" ] ; then Options="${Options} --disable-stdio-redirect" ; fi

I misunderstood how the --disable-stdio-redirect option works. It turns out that it converts your program to a Windows console application, which is not what I wanted. What I want is for the program to behave the way it does under Linux – stdout shows up if you run the program from a terminal window and is lost otherwise. Well, the whole point of this blog is to document the problems that a new game programmer would encounter by actually encountering them, so I’ll claim this as a success! (At least, that’s my story, and I’m sticking with it.)

I’ll work on this some more, but for now I’ll just leave SDL stdio redirection in it’s default setting.

Updated again!
It turns out that SDL 1.3 has removed the Windows stdio redirection enitrely but they forgot to remove the configure script option for it. Now you get normal output if you compile as a console program, and if you compile as a graphical program you need to open an output file and do your own redirection. OK then.