Graphics in C

In this tutorial you will learn how to do 2D graphics in C. We'll actually give the basis for programming up something simple but worthwhile, e.g. a Space Invaders game (taking us back to the Eighties) and it is a lot less complicated than it sounds. Remember, computers of the very early eighties (before C was even used on home computers) all had games like Space Invaders, so if they could do it so easily, then doing a bit of basic graphics should be a piece of cake for us with our modern computers.

We frequently get requests at FriedSpace.com for tutorials on doing graphics in C. It is a very popular subject, and it fits in with the philosophy of our site quite well, namely that people should have fun with their computers and not just use them for work.

There's only one problem: natively, C does not provide graphics capabilities!!

In order for C to be completely portable from platform to platform it has focused on providing platform independent functions, such as file access, text string manipulation, mathematical functions, etc. So in order to get graphics in C, one needs to do one of four things:

The problem is, not all of these options are practical. One could for example, add some assembly language in to the mix in order to add graphics capabilities. But there is a problem with this. Once upon a time, it was easy to do graphics in assembly language. This was when machines were 16 bit. One would simply call processor interrupts which alllowed for a variety of graphics functions to be sent to the graphics card in the PC. One can still do this, but the problem is, one needs to write a 16 bit program. That requires a 16 bit C compiler, capable of compiling 16 bit DOS programs. But pretty soon, 16 bit programs won't be supported at all by Windows (and possibly even by the CPU's in PC's). Therefore, this solution is hardly future proof (though for nostalgic reasons it might be fun for some of us).

One could try writing some 32 bit assembly language code for handling graphics. The problem is, this is almost infinitely complicated, probably not portable from machine to machine and most likely requires some negotiation with the operating system anyway, which means learning how to write device drivers, DLL's and/or low level code for speaking directly to a graphics card. This is certainly out of the question for all but the most advanced computer engineers, and only a few of those visit our site.

One can call the GDI functions provided by Windows itself. One slight problem here is that one then needs to learn Win32 programming. That is a whole "language" in itself, and far too complicated for an introductory, or even intermediate tutorial. The so-called Windows API (Application Programming Interface), the part of Windows that programs communicate with to access features of the operating system, does in fact provide numerous graphical functions. Although this is possible to learn, the nature of Win32 programming is completely different to ordinary console programming in C that we have been learning. Later on we may provide some tutorials on Win32 programming, but they really make advanced tutorials. It isn't just a matter of running a function for drawing a line on the screen, etc. One needs to negotiate with Windows for some space to draw the line, a window, etc, etc. The other problem is, the actual GDI functions can be a bit restrictive and a bit slow for doing really decent, fast graphics of the type we want.

The third option is to use OpenGL. This is a 3D graphics language which most modern graphics cards support. The problem with this option is that one needs a bit of a Win32 program before one can use OpenGL commands (unless one uses SDL). Also, programming 2D graphics effectively in OpenGL requires some mucking around. It is like using a jackhammer to dig up a weed. OpenGL is simply fantastic for 3D graphics programming, and we'd like to have tutorials about that too eventually, but for now it falls into the advanced category. What is more, SDL allows one to hook directly into OpenGL anyhow, and makes OpenGL programming easier, so why not start with SDL. That is not to say OpenGL is a bad option - actually, it's great - but it is just more than we need for now.

The fourth option is to use a graphics library. The only problem is, it is very hard to find a simple graphics library which will work with Pelles C, will be easy to use and which will produce fast graphics programs. One can literally search for months to find one (as I did). But there is one. It is called SDL. We recommend it as virtually the ONLY decent solution to our problem. And it is a good solution.