01 April 2013 21:01
Code::Blocks
For a while I experimented with Code::Blocks (version 10.05) as an alternative to CMake. It made a lot of sense because it targets the exact three platforms that interest me; Windows, Linux and Mac OS X. It is much more convenient than CMake because all project configuration can be performed from within the CodeBlocks IDE.
There is no need to manually edit text files containing obscure commands. I was more or less able to guess the required configurations just by exploring the options in the CodeBlocks gui. I only needed a little bit of help from the documentation and then I was able to build my Alienode project on all three platforms.
This approach is not quite as flexible as using CMake, but I must admit that the IDE for CodeBlocks is pretty good. It’s a good way short of Visual Studio but still very nice. Being able to use the same IDE on all three platforms reduces the learning curve considerably.
At the end of the day I rejected CodeBlocks for this project mainly because I am very familiar with Visual Studio and it is better than CodeBlocks and I expect most of my actual programming could be performed on the Windows platform. Even so, I may continue to play with CodeBlocks when I’m working on Linux, and maybe also on Mac.
One thing to note is that there has since been a major revision of CodeBlocks (12.11 at the time of writing) which may be much better.
CMake ZERO_CHECK macro problems.
One problem I hit recently with CMake is that the Visual Studio ZERO_CHECK macros that rebuild the project files have started to hang on me. I literally have to terminate Visual Studio with Task Manager in order to escape. As a work around I now use the CMake gui to rebuild the Visual Studio project files every time I make a CMakeLists change. I understand this problem is known to the CodeBlocks team and they are working on it. (http://public.kitware.com/Bug/view.php?id=11258#c27652)
Alienode project status
As it stands, the Alienode project is still wafer thin. It consists of a custom exception class, a logger that can write log messages to a file, a method to get the current time, an application abstraction class and a handful of unit tests. There is a very tiny ‘demo’ console application that does little more than logging the target platform and the build number!
I have also added bindings for libcurl so that I can make web requests, but I’m not really using it yet. The idea was to allow a client application to check if there is a more recent version by making a simple web request. Also, I considered the possibility of reporting exceptions or even the entire log file to a central web server. This now seems a bit premature so I have put it on hold for now.
This week I have started to develop an Opengl demo using glfw and glload (from the Unofficial Opengl SDK). I’m using “modern” Opengl with version 3.2 and the core profile. Currently I’m rendering a simple triangle using the simplest possible vertex and fragment shaders.
glfw is a cross platform window toolkit library for creating an Opengl window and context. It has a similar function to glut, freeglut or SDL. Glload is a cross platform loading library for opengl that obtains function pointers and signatures for opengl extensions. It has a similar function to glew.
I have decided to start with the Opengl 3.2 core profile mainly because it is the most up-to-date version supported by Mac OS X. It is possible I will end up with multiple rendering ‘back-ends’ that support more recent versions of opengl for Windows/Linux and maybe Direct3D, or even an older version of opengl (2.1?). Opengl 3.2 is the common denominator so that’s where I plan to start.
06 October 2011 08:42
Today I started a new software project with ‘alienode’ as the working title and this blog will be used to record
it's progress. Alienode will be a cross platform C++ game engine and as I start this blog I have a clean slate – the engine is vapourware right now.
I thought it might be interesting for people to see how a game engine is created
right from the very start.
I want the alienode project to build on both Windows and Linux (and on Mac OS X in the future).
Ideally I should test the engine on all the target platforms right from the
start but I don't yet have access to an Apple Mac. So I have been investigating build tools for use
on all three platforms. Top of the list is CMake which is described as a cross-platform, open source build system.
CMake allows a programmer to define one or more C++ projects using text files
called “CMakeLists.txt” that are usually stored alongside the source code. Using simple commands these configuration files specify the name of the application or library, the list of source files to compile and the location of any include folders or dependent libraries. When CMake is executed, it reads the CMakeLists.txt files and generates project files for one of several different C++ compilers or IDE’s. In my case I generate one solution for Visual Studio 10 on Windows, and a Unix makefile for gcc on Linux. CMake supports various other targets such as CodeBlocks and Eclipse CDT but I haven’t tried these out yet.
The nice thing about using CMake is that I only have to maintain the project definitions in one place (the CMakeLists.txt files) and never have to worry about synchronising the project definitions in Visual Studio with the Unix makefiles. When I add new C++ source files to a project I just edit the CMakeLists.txt files and regenerate the Visual Studio solution and Unix makefiles as needed.
I will probably do all the actual development work in Visual Studio so I might not need an IDE for Linux. The source code itself will be stored in Subversion, even though this is a one-developer project.
The source code and CMakeLists.txt files will be stored using version control
but the generated Visual Studio solutions and Unix makefiles will not.
When CMake generates a solution for Visual Studio it creates a couple of extra projects called ALL_BUILD and ZERO_CHECK. ZERO_CHECK can perform a comparison between the CMakeLists.txt files and the Visual Studio project files and automatically invoke CMake to re-generate the solution if it notices any differences. This makes it possible to maintain the CMakeLists.txt files whilst working in Visual Studio and keep the project definitions synchronised. When I add a new source file to a project using Visual Studio, I just add
a reference to it in CMakeLists.txt and rebuild the ZERO_CHECK project. This usually causes Visual Studio display various popup dialogs and to reload the modified projects. Not exactly seamless but better than closing Visual Studio, running CMake and reloading Visual Studio. I need to experiment here to see if I can find a smoother work flow.
At this point alienode consists of just three skeleton C++ projects. The first is UnitTest++ This is a lightweight unit testing framework that supports the same three platforms. I also have a static library for the main alienode engine and a console application for the engine's unit tests.
This project structure allows me to keep unit tests separate from the main
engine.There is nothing in the engine project or the unit tests project yet except for a dummy test. Although it does nothing
interesting, it is useful for checking out the features of CMake and it provides
a good jump off point for Test Driven Development.
So far, it looks like CMake could be a very useful tool for this project but I’m not yet certain about my other choices such as Unix makefiles and Visual Studio 10.