I’ve started thinking about writing my game engine in pure C because I think as OOP as C++ is, it makes things rather longer and more complex – mostly because it adds more code by default and more abstraction when its not needed. The issue I have is that by default you’ve got it and it goes on and on and on from there until you have a large codebase with lots of stuff in it and you forget what the design you used is all about because you’ve made a class for just about everything, then you’re jumping around the codebase trying to piece it all together – seemed like a good thing to do at the time!

SDL for instance is written in C and a lot of people interface their C++ code with it.  I downloaded SDL version 2 and started seeing how it works. First of all its incredibly easy to obtain and setup, I was impressed. I had visions of it being a mammoth task something akin to setting up Windows Driver SDK or worse. I set it up in visual studio 2015 and it was just a matter of downloading the library and linking against it. So in Visual Studio, a quick couple of teaks to the linker and include directories is all you need.

A lot of books on 3D graphic rendering and game engine are written in C++. Perhaps it will soon become apparent to me why this is. Is it just convention, much like Java is to students learning OOP, c++ is to game coding? I have seen game engines written in C so I’ve not really put off from going against the grain? Doom was written in C and if C is good enout for ID Software, C is good enough for me. boom.

Anyway, I got a simple SDL window up and running, a primitive game loop and could paint things onto the screen. When I say things, its just a static picture within the confines of a window. I know, advanced stuff huh?  I got to know some SDL concepts such as SDL_Surface, SDL_Window, SDL_Renderer, SDL_Texture and how to initialize the SDL system. I also learned, mostly from lazyfoo’s tutorials online, how to incorporate some SDL extensions to load .png files and interact with the keyboard. The thing about all of this is that I’ve been itching to put my game loop to the test. I wrote or rather took advice from a professional-grade game loop I read in “Core Techniques and Algorithms in Game Programming” which explained pretty much all the elements that make up a game loop, from updating the players status, updating the world, rendering, animation, AI and everything it seems into a good structure. I’ve replicated that structure with placeholders for all those tasks. I wanted to fill some of them in. SDL is my “cheat” to see what i could put where. And so far, I’ve seen that I can fill in some code in the game loop using SDLs controller/input code and perhaps some very rudimentary initializing of the graphics in the game loop:

So today I took my game loop that I’d been working on and incorporated much of the above code(just to get a SDLWindow up and running and showing a picture) into that. This is good because I’ve moved from Visual Studio and a dependency on Windows()I was using timegetTime() Win32 API function for determining the framerate of my gameloop) to running all of this under Mingw, incorporating both my C library(stulibc), glib(yay!) and SDL into one autotools project. Their is a slight bit of hackery around using hard coded paths for stulib’s include and lib files along with the same for using SDLs Image extension. Also it seems i cannot use the main stulib.h header file at the moment so I’ve resorted to using specific header files for specific functions – like safettchecking.h for CHK_ExitIf() function, which I use to initialise/check some SDL functions.

And because I’ve factored the SDL code into my original game loop in C, I’ve started to fill in some of the pieces that were missing in the game loop, namely the sense_player_input() function which now boasts a rudimentary event loop query to determine what the user is doing at the keyboard. Currently it just prints out “up”, “down”, “left” and “right” when you hit these keys on the keyboard, while processing the game loop.

The other great thing about all this is that under mingw, I’ve effectively made large inroads into being able to develop in both Windows and Linux and hence be cross-platform – specifically I’ve got a POSIX environment. For instance, I’ve been able to replace the Win32 time function timegetTime() with glib’s own version, g_get_real_time() so this makes it work on any of the two platforms. Also being SDL, I’ll have again appeased my cross-platform ambitions by its very existence – its a cross platform library. When I need to make the leap (and it probably is a leap) to 3D graphics rendering, SDL will thankfully be able to use Direct3D under windows and OpenGL under Linux.

Granted I’ve only touched the surface of all of this, writing all this in C makes me happy. I wonder if I’ll be forced to move to C++? I suspect not, but perhaps its possible to use a hybrid approach? I would certainly think that incorporating a scripting language for the AI might introduce OOP at the point that really its needed. I’m not too sure OOP is really needed for low-level game engine stuff.

So now I’ve got the best of both worlds, I can run it potentially in Linux and Windows. I’ve linked it against stulibc so I have access to my functions, I’ve linked it to glib so I have access to some other cross platform functions such as advanced data structures and functions and we’re using SDL in a autotools configuration so it should be fairly easy to do this all again under Linux. Woohoo!

I’ve ordered the following books:

Game Coding Complete: This is probably the best book I can see on what I’m undertaking to learn. I looks like the kind of book, “Core Techniques and Algorithms in Game Programming” is – eye-opening.

Game Engine Design and implementation: I’m not expecting miracles from this book, I am from the one above but this is a fallback that might turn into a gem!

3d Games:Volume 1: Real-Time Rendering and Software Technology Vol 1: Real-time Rendering and Software Technology: This is just because I’m new to 3D and need some basics This is old but so are the basics.

And the anti-climax we’ve all been waiting for:


It’s a red box. I know, but not just any red box – oh no! Its a red box that moves when you press keyboard buttons. It also has two blue lines – there is a genius at work here, watch this space!

That is all…for now Smile

Comments powered by CComment