Skip navigation

Tag Archives: ogre

I noticed I still haven’t blogged about a project I worked on some time ago, so here goes.

A long time ago I wrote a small library for wrapping OGRE in Haskell. I wrote it manually, i.e. first writing some C functions that call C++ and have a C interface, and then wrote some Haskell functions to call the C functions. That’s the principle when wrapping C++ libraries in most higher level languages, mainly because most language implementations support calling C, but not C++.

Now, by writing the whole wrapper manually you have the complete power of the resulting interface, so you can try to bend the C interface so that the resulting interface has the natural feel of the higher level language you’re writing the binding for. The negative side to this is, of course, that it’s lots of work, and more or less tedious at that. There are therefore a lot of programs that automate some or part of the process of writing bindings to C libraries. So when wrapping a C library for Haskell, you can use a tool like hsc2hs, bindings-DSL or c2hs.

But it gets more problematic when you want to wrap C++ code. In the end you somehow have to wrap the C++ code to C – either manually or automatically. Some C++ libraries maintain their own C wrappers, like bullet and LLVM. For others, the wrapper writers must either write or generate their own C wrappers. When it comes to Haskell bindings for C++ libraries, the C wrappers were written manually at least for Irrlicht. I also wrote the C wrapper manually for the first versions of Hogre. As for the libraries that generate the C wrapper using a tool, there’s at least qtHaskell.

Now, at some point it got tiresome to manually write the Haskell bindings to Hogre, so I wrote a tool to automate it. Actually, there are two tools: cgen is a program that parses C++ header files and creates a C wrapper around the C++ library, and cgen-hs is a tool that parses the generated C header files and creates a Haskell wrapper around the C library. Using these two tools I created the newest version of Hogre, which is a lot more complete than the previous, manually written binding.

I also wrote a small example on how cgen works that I’ll demonstrate here. The input is Animals, a C++ library that allows access to a programmatic use of a wide range of animals. It’s a header-only library because I wanted to keep it simple, but that doesn’t really make a difference here. It’s split across three header files, listed here:

namespace Animals {
class Animal {
        Animal() : age(0) { }
        ~Animal() { }
        virtual void make_sound() = 0;
        int get_age() const
            return age;
        void increment_age()
        int age;
class Dog : public Animal {
        Dog() { }
        void make_sound()
            std::cout << "Growl!\n";

class Sheep : public Animal {
        Sheep(int wooliness_level_ = 0)
            : wooliness_level(wooliness_level_)
        { }
        void make_sound()
             std::cout << "Baa!\n";
        void shear()
        { /* something */ }
        int wooliness_level;

So, given this piece of code one can feed it to cgen, which generates a C interface for it. The result looks something like this (simplified):

/* Sheep.h */
void Animals_Sheep_delete(Sheep* this_ptr);
Sheep* Animals_Sheep_new(int wooliness_level_);
void Animals_Sheep_make_sound(Sheep* this_ptr);
void Animals_Sheep_shear(Sheep* this_ptr);
/* Sheep.cpp */
void Animals_Sheep_delete(Sheep* this_ptr)
    delete this_ptr;

Sheep* Animals_Sheep_new(int wooliness_level_)
    return new Sheep(wooliness_level_);

void Animals_Sheep_make_sound(Sheep* this_ptr)

void Animals_Sheep_shear(Sheep* this_ptr)

So there we have a C wrapper for a C++ library ready for compilation.

For writing the Haskell binding, the next step is to run the next tool, cgen-hs. It takes the generated headers of the C wrapper as input, and as output creates a Haskell library that wraps the C library. The output looks something like this:

{-# LANGUAGE ForeignFunctionInterface #-}
module Sheep(


import Types
import Control.Monad

import Foreign
import Foreign.C.String
import Foreign.C.Types

sheep_with :: Int -> (Sheep -> IO a) -> IO a
sheep_with p1 f = do
    obj <- sheep_new p1
    res <- f obj
    sheep_delete obj
    return res

foreign import ccall "Sheep.h Animals_Sheep_delete" c_sheep_delete :: Sheep -> IO ()
sheep_delete :: Sheep -> IO ()
sheep_delete p1 =   c_sheep_delete p1

foreign import ccall "Sheep.h Animals_Sheep_new" c_sheep_new :: CInt -> IO Sheep
sheep_new :: Int -> IO Sheep
sheep_new p1 =   c_sheep_new (fromIntegral p1)

foreign import ccall "Sheep.h Animals_Sheep_make_sound" c_sheep_make_sound :: Sheep -> IO ()
sheep_make_sound :: Sheep -> IO ()
sheep_make_sound p1 =   c_sheep_make_sound p1

foreign import ccall "Sheep.h Animals_Sheep_shear" c_sheep_shear :: Sheep -> IO ()
sheep_shear :: Sheep -> IO ()
sheep_shear p1 =   c_sheep_shear p1

Then one can write a Haskell program using this new Haskell library, and run it for the output:

$ cat Main.hs
module Main

import Control.Monad (replicateM_)

import Types
import Animal
import Dog
import Sheep

main = do
  dog_with $ \d -> 
    sheep_with 1 $ \s -> do
      dog_make_sound d
      sheep_make_sound s
      sheep_shear s
      replicateM_ 5 $ animal_increment_age (toAnimal s)
      animal_get_age (toAnimal s) >>= \a -> putStrLn $ "The sheep is now " ++ show a ++ " years old!"
$ ./Main
The sheep is now 5 years old!

So, everything seems to work well, and the newest Hogre version can be found at Hackage, as well as cgen.

Cgen is, however, in a very early stage of development and has, therefore, some weaknesses. First of all, it’s not a complete C++ parser, not even close, so it fails to parse many C++ header files. After configuring it for OGRE, it does manage to parse about two thirds of the OGRE headers, which is a good start, I guess. The C++ parser was the first real parser I wrote using Parsec, so a rewrite is probably the way to go.

Second of all, as I’ve only seriously used cgen for OGRE, it makes some assumptions about the C++ headers that may not hold for other libraries. The most critical one is probably that cgen-hs expects that all the classes and functions to wrap are in some namespace, which leads to problems when wrapping libraries that reside in the global namespace.

The third weakness is that it the generated Haskell functions are simply all in the IO monad, which suits well for OGRE (which doesn’t really have that many pure functions), but may be far from ideal for another library. Finally, cgen currently doesn’t support any class templates, neither wrapping them or using them as parameters or return values, so wrapping interfaces that rely heavily e.g. on STL will be troublesome. For Hogre this is not really a killer, although it does prevent the Hogre user from using some features that are available in OGRE.

All in all, however, cgen is working well for Hogre, and if you’re planning on writing a binding for a C++ library, you can give it a try. For more information, see the cgen homepage, a simple example, and the Hogre homepage.


If you’re planning on writing 3D software in Haskell, here are some tips.

A few months ago I was planning on programming a 3D game in Haskell and was browsing the options for a 3D library. In general, there are a couple of low-level APIs (OpenGL and Direct3D) and a few higher-level libraries built on top of those low-level APIs (OGRE, Irrlicht, and more).  Using a low-level API has the known advantages (fine-grained control) and disadvantages (lots of code to write).

It turned out that limiting the programming language to Haskell is quite restrictive; almost all higher-level libraries are intended for using with C++ (Panda3D being an exception with Python as the intended language; the library itself is written in C++, though). So what you need is Haskell bindings for the libraries. There’s a Haskell binding for OpenGL, which is used for (apparently) all 3D games written in Haskell. A few months ago it was the only option and, if you’re doing anything more complicated than rendering a few models in a scene, it still is.

The problem is that binding a C++ library is rather complicated and basically boils down to either writing C code to wrap the C++ interface and then interfacing the C code in Haskell using FFI or automatically generating the C interface (as well as the Haskell FFI code that wraps it). The latter option was chosen for at least the GUI widget libraries wxHaskell and qtHaskell.

However, a few Haskell bindings for 3D libraries have appeared. There’s a very primitive binding to OGRE written by the author of this post (with examples) as well as at least a start of a binding to Irrlicht by Peter Althainz.  So there appears to be a bit of activity regarding the use of higher-level 3D libraries in Haskell, which is good news, I guess.

One more note regarding the Haskell bindings for Ogre: you can do some simple things like adding models and a camera, and moving them around, but that’s about it, since I haven’t really had the motivation or need to provide support for anything else. The bindings are relatively simple to extend, though, so if you use the bindings and miss a feature, go ahead and let me know.

New year, new tricks. In this post I’ll explain what Freekick has been doing for the last two months. The main events include rewriting Freekick in C++ so that it finally matches the Haskell version feature-wise, as well as gaining a bit of experience in using the associated tools and libraries. Before I get to that, let me first write down a brief summary of the last year, and of the blog thus far.

In April I wrote the first post announcing the beginning of the project, wondering which language and graphics library to use. The decision was in the end to go for C++ and Ogre. I was also preparing CEGUI as the GUI library. The build system was make, the version control system used was Subversion (if any).

In May I got to physics libraries and decided to look at ODE instead of Bullet. Soon after that I’d let the physics and graphics digest for a while and learn Haskell instead as a tool for AI programming.  Back then, there was no real code written for the project yet.

In June I had learnt the basics of Haskell and was using it to program some of the first things in Freekick.

In July the very basic design of Freekick was slowly getting clear. The plan was (and is) to split the game to different processes and use a server-client model. I went on programming the server and the AI in Haskell and played with the thought of writing the client in Python. I also started getting VCS conscious and mentioned darcs for the first time.

By August I had gotten as far as programming some multithreaded networking in Haskell, as well as doing some nice experiments and tests with neural networks. While the networking part was directly a part of Freekick at the time, I haven’t integrated the concept of neural networks with the project yet.

In September the very basic structure of Freekick, including the server, AI and a client, was finished in Haskell and the version 0.0.1 was released. The client was written using SDL, the primitive physics for the server was done without external libraries and the AI was a simple decision tree.

In October the negative sides of Haskell were starting to become clear, mainly being problems with the performance and problematic use of C++ libraries. The decision was to write a new client in C++ that uses Ogre for graphics. Implementing the data structures (classes) in C++ for the client also makes writing the server in C++ not such a big step.

In November the new client was finished. As it became clear that the performance problems had more to do with the Haskell server than with the client, the decision was to rewrite the server in C++.

In December I didn’t have the time to write about it, but I was busy rewriting the server in C++. This included updating the protocol between the server and the client as well as learning object oriented design.

And now, in January, it’s time for a post again. The C++ server is running, and the preliminary AI is finished too. As there were some updates to the Freekick protocol that broke the backwards compatibility; the old Haskell programs (server, SDL client, AI client) would have to be updated to match the new protocol in order to be able to work with the newer software (maybe I’ll get to it on some rainy day).

As there are some difficulties finding a public code hosting site for darcs repositories (and darcs seems to have some other problems too), I went for another RCS, namely git. I too am one of those who don’t want to go back to centralized SCM after seeing the other side, and git seems to fit my needs perfectly. The Freekick code can be found at GitHub by the way, at If you want to compile and run it though, there are some external dependencies (notably Bullet and Ogre) and the build script probably isn’t portable yet. If you run into problems, drop me a note.

As a side note, I also wondered which build tool to use for the C++ version of Freekick (for Haskell, Cabal is the excellent build tool, while C++ has a lot more options). The two strongest candidates were CMake and SCons, and in the end I went for the latter. The build tool for Freekick has the seemingly complicated task of compiling and managing a few libraries and applications, preferably comfortably configured in one configuration file. By now, my SCons build script (SConstruct) has become about 150 lines, but it does everything I want it to and how I want it to. The level of documentation for SCons is also excellent.

Now, a few words about implementing Freekick. First of all, even though C++ is more comfortable than I previously thought, it’s still far away from Haskell. My impression is that, thanks to the Boost libraries, you can use most of the nice things that Haskell has (e.g. tuples, lambdas), and everything will run slightly more efficiently than in Haskell, but there’s a lot more code to write and the code is a lot less elegant and a lot more verbose than in Haskell. I guess the better control of CPU cycles and bytes of RAM is worth it.

An interesting thing to note is that it took for both Haskell and C++ about three months to implement the basic functionality of Freekick. The comparison is unfair; I had just learnt Haskell when I started programming Freekick with it, while I’ve had previous (albeit now rather obsolete) experience with C++. Also, when I programmed Freekick the first time, the basic structure and design was only barely clear to me. With Haskell I had to program my own primitive physics engine, with C++ I used Bullet (which was about just as troublesome). The Haskell graphical client was easily done in SDL, while the Ogre client was a bit more work (though using Ogre is actually quite fast, easy and fun – signs of an excellent library). However, in the end the difference in development times wasn’t drastic, which shows to me that C++ really seems to do the job of evolving to a higher level language with time pretty well.

This was also the first time that I’ve actually done some object oriented design. It’s actually quite fun. The constant shuffling around with the header and cpp-files and the verbosity of it all is something I wouldn’t miss with Haskell, and the generic programming and code reuse that OOP offers is still light years away from the level you can find in a functional programming language. Still, C++ is on any account usable and I really need those cycles and bytes. Hopefully in a few years I can use a language that is as elegant as Haskell, while still maintaining the perceived efficiency of C++.

The next things to do with Freekick include relatively small improvements to the server (better compliance with the rules of the game), to the AI (it’s really quite primitive at the moment) as well as to the client (controlling a player and some small graphical enchancements). After that the next task is to go and implement the bigger plan, i.e. the game around the match – organizing the matches into cups and leagues.

A few weeks ago I wrote I’d try and write a new Freekick client using OGRE3D and C++. The reasons for this seemingly dramatic language switch from Haskell were manifold; the top one being the jittery feeling in the old SDL client, apparently resulting from some timing issues regarding my thread management in Haskell I wasn’t able to sort out. Another thing that greatly influenced the decision was that I had split the whole project in multiple processes already during the design; since the processes communicate with each other via sockets, reimplementing one part (even in a different programming language) is relatively easy.

The first version of the OGRE client is now finished, and it has about the same functionality as the very first version of the SDL client: the user is doomed to be a spectator as there is no way to control a player, the only controls available are merely for moving the camera around. I personally found it very interesting to see the functionality of both the server and the AI through a different client; of course the rest of the functionality has stayed the same and the AI is as stupid as usual, but now it’s robots instead of red and blue squares kicking the ball.

Oh, here are some screenshots of the new client. Obviously, there a lot to be done (more than the pictures can describe), but it’s a start.

OGRE client
Top-down look

Another thing I find rather exciting is how easy it is to produce software these days that has features I could only dream about five years ago. Back then, programming multi-threaded networking or 3D scenes with custom meshes and lighting (including shadows) was a nightmare (for me at least), but nowadays (especially with the aid of such terrific libraries as Boost or OGRE) I can spend more time programming the essential things.

A few words on the design of the new OGRE client. I wanted it to have three distinct parts which communicate with each other via simple interfaces (true to Rule of Modularity) – networking, graphics, and match state. The basic idea is that the networking part receives information about the match state from the server and writes it in the state part. The graphics part renders the scene and reads the information for this from the state part, so the state acts as a kind of broker between networking and graphics. As only one part writes and the other one reads the mutable, shared data there shouldn’t be big problems arising with multi-threading, either (I hope).

The question is, then, is the jittery feel from the SDL client gone with the OGRE client? The answer is (to my surprise) no. Last time I wrote about the timing problems in the networking code between the server and the client; specifically, even though the server was set to send the player positions every 20 milliseconds and the client should draw them every 20 milliseconds, the jitter was clearly noticeable. My conclusion at the time was that the client wasn’t updating the graphics fast enough and that I’d need to write a new client in C++ as a remedy.

Now, as the new client is functional enough to show the jitter, I investigated the problem more and, using the Date_time library from Boost I measured the frequency with which the server actually updates the client. It turned out that instead of sending an update every 20 milliseconds, the client receives a scene update only every 250 milliseconds, which obviously is much too slow.

I actually measured the interval between updates before I started writing the new client and came up with the said 20 milliseconds. The difference is, back then I measured the interval on the server side, not on the client side – which means that some obscure bug in either the thread management code or in the network code kept the data on the server before it was actually sent.

I also tried implementing a very primitive client side prediction on the OGRE client as a test, but the interval of 250 milliseconds is still too much for a smooth scene. I also came across some very interesting resources by Valve regarding multiplayer network programming, and while I’m not so sure I’m willing to implement entity interpolation like they did or if doing that would even work so well in a soccer game, the article still gave me some hints what could be done better on the server side.

The last time I wrote I’d consider rewriting the server again using Bullet as the physics engine, and now that I’ve discovered the problems regarding the network code on the server side as well my next task seems pretty clear. I could try to fix the issues in the Haskell server code, but it seems a bit too much at the moment, and I’m already looking forward to getting my hands dirty on Bullet. That means (to the disappointment of the fellow Haskellers) that soon the only part written in Haskell (not counting the older, yet very usable client) will be the AI, which also needs to be improved a lot in the future. I still think Haskell is a great language though and I’ve learnt unbelievably much from it (as Simon Peyton Jones says, “Even if you’re going to go back to C++, you’ll write better C++ if you become familiar with functional programming”), but I’m afraid it’s not the best tool for this job.

For those of you who are interested, I haven’t yet uploaded the code for the new client in any repository. It wouldn’t be suitable having the code on, and I don’t know of any other public source code repositories for darcs, which makes me look for other revision control systems. After my experiences with darcs I’m determined to stick with a distributed RCS, and git seems like a good option, but before making the final decision I’ll check out the other options (e.g. Mercurial). Once I have the URL I’ll let you know.

Following the 0.0.1 release of Freekick and an update to 0.0.2, I started noticing some problems in the implementation that showed a need for code refactoring. There were certain issues that implied I should find out about the internal workings of Haskell, as in, trying to figure out how the language and the implementation I use (Glasgow Haskell Compiler) works in general, especially with regards to threading, scheduling and performance.

The first issue I ran into was about my physics engine. I had defined a maximum velocity for my players of 8 m/s, but after some measurements I found out they were instead quite a bit slower. (A tip for the future: implement a debug panel for having such information when you need it. Measuring something like that shouldn’t be necessary.) This implies that the physics engine has serious flaws. I improved the engine slightly and it works slightly better now (but still not as well as it should), but the improvements lead not only to faster players, but also to strange twitching, a flicker-kind of effect on my SDL client.

To figure out what causes the flicker, I needed to check the code for networking. The way my networking code works at the moment is that the server (physics engine) only sends the positions of the players to the clients but no velocity or acceleration, and my SDL client doesn’t calculate the velocity of the player but only places the player where the server tells the client to. This is the simple method used in Quake that lead to problems back in 1996 when 56k baud modems were fast: with a lag of 200 milliseconds and occasional packet loss the client would spend most of the time not knowing where the moving objects (a.k.a. targets) were exactly located. The remedy that id came up with (a technique that was also used in Duke Nukem 3D) was brought to life in QuakeWorld, where the client would “assume” where the players would be located in based on their current/last known position and velocity. This made Quake playable (and a huge online success) even with slower connections (at the time I had a mere 14.4k modem). The technique is called client side prediction and there’s a small section written about it in Wikipedia.

Now, since I don’t expect a crowd of modem using people starting to play Freekick over the Internet, I didn’t implement client side prediction. Since I have the Freekick server and client running on the same computer lag shouldn’t be the cause for twitching anyways. But to make sure the client was receiving updates about the match state fast enough, I raised the server refresh rate, that is, the frequency with which the physics engine sends the match data to the client(s). The delay between refreshes was 40 milliseconds (using threadDelay), which should actually be enough, but I dropped it to 20 milliseconds for testing. Now, with the lightweight threads that Haskell offers (using forkIO) the refresh rate went up indeed, but the flicker stayed. I tried compiling with the “-threaded” parameter, which made the situation only worse, as the minimum thread delay time using “threadDelay” went up to 40 milliseconds on my computer. In the end I stayed with the lightweight threads, which doesn’t really affect my single core anyways, but this points out a problem when optimising the engine for multiple cores.

However, the problem persisted. Since my CPU was still nowhere near 100%, I figured the problem has something to do with how Haskell handles high precision timing. I’ve tried Frag (a 3D shooter written in Haskell) on my computer, and while I was overall impressed by the game, it was hard not to notice how Frag was twitching with regular intervals as well. As I don’t know if there exists a remedy for the problem, nor if the cause indeed is something Haskell specific or just some obscure bug in SDL or in my client, I wanted to go for a completely different approach.

That’s where C++ comes into play. I’ve actually had quite negative opinions about object oriented programming as well as C/C++ in the past, but on the other hand there are some rather impressive and useful libraries available where bindings to Haskell don’t exist and can only be implemented with a lot of work. The library that I thought of first was OGRE, the massively powerful 3D graphics library written in C++. There are actually a couple of articles about calling C++ functions from Haskell (see here and here), but binding a library like OGRE to Haskell using the described methods is not really something I’d like to spend my free time with.

I know that using OGRE for the client side would

a) make the client run faster and with no flicker, and

b) maybe even look a bit nicer

than the current client implementation using SDL, Haskell and 2D pixel-by-pixel drawing methods. The middle way would be to use the apparently very well written Haskell bindings to OpenGL, but I didn’t really enjoy OpenGL very much the last time I used it five years ago and after seeing OGRE in action and realising using OGRE is actually easier than using OpenGL I don’t really have the motivation. Of course, the biggest reason to use OpenGL would be that I could keep on writing the client in Haskell, but in the end it’s probably easier and more effective using C++ and OGRE.

That being decided, the next thing to do was to freshen up my C++ knowledge. I actually never had much of formal education to C++, instead I was using it much like “C with classes”. Even though that was the primary objective of C++ in the beginning, modern C++ is a completely different subject that I somehow had failed to miss until now. So I went and got me the book The C++ Programming Language by Bjarne Stroustrup and studied it through. I can imagine that a lot of people who have no or very little experience with C or object oriented programming find the book confusing, but for me as someone with good knowledge in C and some idea what C++ is about the book was perfect: it explained all the ways C++ can be used to make programming more efficient and less error prone.

I think it’s time for a small analysis about programming languages. After using C and assembly language I’ve gotten a pretty good picture about what the lower-level job of compilers is: shuffling around with the registers, allocating and keeping track of memory, testing for bits and so forth. Languages like C build on top of this, making the whole resource and control flow management easier to write and read.

On the other hand, Haskell approaches the problem from the other side. Haskell is designed from a mathematical point of view while trying to improve the efficiency of the programmer without clinging to the requirements and constraints of the machine, making Haskell code elegant and robust. To me, writing code in Haskell is almost like using a perfect programming language. Between C and Haskell, there’s C++. My impression about C++ was originally (unsurprisingly) that it is not far away from C, but after seeing how C++ improves on C and adds language features that allow the use of completely new programming paradigms (to C), C++ seems more and more Haskell-like to me.

With Haskell I learned to love the fundamental functional programming features that first seemed a little strange to me (like currying, higher order functions, lambdas etc.). I thought with C++ I’d be giving them away in exchange for pointer arithmetic, buffer overflows and unsafe typing, but fortunately I couldn’t have been more wrong. Nearly all of the C features that don’t seem to fit to modern software development are completely unnecessary in C++, and a lot of functional concepts and other features I’d miss from Haskell are brought in either as built-in C++ features (e.g. safer typing, better mutability control), the standard library (lists, currying, higher order functions) and Boost libraries (smart pointers for memory management, lambdas, serialization).

If you check out the Programming Language Shootout, you’ll see that C++ is (as expected) usually faster than Haskell (but the difference is not tremendous). As is also very well known, there exist about ten thousand times more libraries for C++ than for Haskell. In my opinion, those are pretty much all the aspects where C++ is “better” than Haskell. On the other hand, Haskell code is easier to reason about, significantly shorter and therefore easier to read (in my opinion, at the very least) and the concept of type classes is something C++ and the templates still have a lot to learn from, making generic programming far easier and simpler in Haskell than in C++. However, when writing a client for Freekick, performance as well as external libraries do play an important role in the end, and therefore I’ll go for C++. I’m glad I’ve seen Haskell as the finest example on how elegant code can be written, and I’m also glad it’s easy to use the same concepts in C++.

The next thing I’m going to do is read some more about object oriented design (I’ve got Design Patterns waiting for me) and then go and implement a simple Freekick client using OGRE. For that I need to reimplement the Freekick library in C++ as well, which is a nice exercise for OO design (you should plan to throw the first one away anyway, right?). Having the library in C++ would in theory also make it possible to rewrite the server part in C++, in which case I could use a top notch physics library like Bullet as well. But first we’ll see how the client turns out…

In my last post I was writing about dynamic animation. I was researching the topic a bit and made a small plan on how to actually implement the technique. As it basically boils down to three steps – ragdoll without any muscles, ragdoll with joints and an ability to move the body parts with them, actual animation by defining the movements using these joints and muscles – I started with the first step, which is my own ragdoll class. However, after working with the subject for some time I got tired of it and decided it was time for something else. I often feel like having an overdose of some particular subject, where I have the feeling it’s for the best to give the problem some time and rather concentrate on something else.

So I will be returning to dynamic animation at some point, but for the past week or two I’ve been going for something completely different. Luckily I’m going for a soccer game, which means there are a lot of construction sites to work on. Basically the game is divided to two parts – the actual soccer game on the pitch, and everything around it including the managerial and organisatory things like creating and updating league tables, calculating the results of the matches not shown etc. So I decided to take a look at the latter side of my project for some time.

In my first post I was wondering about which programming language to use with my project. I can’t remember if I wrote anything about functional programming languages back then, but ever since I realised how handy they can be when working with lots of arrays or lists (such as league tables) and AI (both the player and the manager AI) I’ve been wondering about using a functional programming language in my project. The problem is, I don’t have any experience in programming with them and they seem to have a reputation of being not so easy to learn once you’ve gotten used to the imperative style.

The good thing is that I’m willing to learn from my project. That was why I also went for Ogre and ODE; I didn’t choose them thinking I’d master them in a week, instead I was willing to make the effort and learn them because they’re effective, even if they’re not the easiest libraries to use. And since my past programs with AI haven’t really ended up as I wanted, I wanted to take a look at the world of functional languages. I decided I’d take the time to try and learn Haskell, a lazy, purely functional programming language. While I won’t go to details in explaining what that means (you can go check it out at Wikipedia or Haskell website), the point is that the code written in Haskell is supposed to be shorter, easier to read and to maintain and contain less bugs… If you know how to program in Haskell. So I’ve been going through some tutorials on Haskell (and will be going through them for a long time from now on, I think) and I’m quite impressed with it.

In my next post I’ll hopefully be able to explain a bit about how to use Haskell and how it could be used in my project. (At the moment I’m still too shocked about the new way of thinking to comprehend how I could actually program something with the language.) While I think I have a long way ahead of me with Haskell, I also have a feeling I won’t regret it. After all, I’m already now seeing programming somehow in a whole new way, so that I even see programming in C from a whole new perspective, a perspective filled with pure functions, lists and pattern matching… That can’t be such a bad thing, right?

Time for a small blog entry again. I’ve been going through the Ogre tutorials and after feeling more confident with the whole graphics rendering I decided it was time for the next step: integrating physics with the graphics. Ogre lets (or, as the critics put it, forces) the developer choose a physics engine suitable for his needs. I checked Wikipedia and the Ogre Wiki for some available engines and came to the conclusion that I’d have to choose between Bullet and ODE (I’d rather avoid commercial and closed source engines). Being impressed with the ODE documentation and the list of ODE users, I decided for the latter.

There are wrappers between Ogre and physics engines that make the life of the developer easier. The problem with integrating the two types of engines is basically that both Ogre and the physics engines have their own formats or classes for basic mathematical elements such as vectors, degrees and matrices and the wrapper has to convert them. Moreover, things like the Ogre timing system, nodes and entities have to be integrated with the physics engine. Since OgreODE, the ODE wrapper for Ogre, does not quite describe its functionality with as much detail as ODE I thought for a moment about just skipping the wrapper and using ODE directly with Ogre, doing the aforementioned conversions by myself – but after seeing the work needed I decided to go for OgreODE after all. The source code should be enough documentation anyways… Right?

After messing around with OgreODE a bit and trying out a couple of tutorials it does seem to work pretty well after all. My first test scenes involved the typical boxes bouncing onto the floor and each other, but soon I wanted to go and try out some physics that would really be useful for my game project, namely rag dolls and dynamic (procedural) animation.

I’ll explain quickly what dynamic animation is. First of all, there’s a nice video showing the technique at Youtube (link), the original thread at Ogre forums can be found here. (But don’t click on the links if you’re arachnophobic…) Basically it means the movements are not preanimated but calculated physically instead, and the characters move their joints themselves by applying forces on them with their muscles. This may sound complicated, but in the end it’s just a rag doll with enough intelligence to move itself. They can, however, be hugely flexible and can do anything without making the player feel bored. In other words, a character can really interact with the surrounding world with its limbs, i.e. when a soccer player gets tackled he falls realistically based on the angle from where the tackle came instead of simply doing a preanimated sequence.

The flexibility that dynamic animation offers is not the only reason I want to implement it. As some well known developers have said, a good developer has to be lazy. Manually animating all the sequences that a dynamically animated character is capable of would be way too much work. On the other hand, if only x animation sequences were to be animated, like a few sequences for the kicking, jumping and tackling actions (which would already be a tremendous amount of work), it wouldn’t really be any easier nor less work to make that look realistic in a soccer game than with dynamic animation. If I teach the players to do the actions with their muscles instead of animating them, I save the work on animating the falling down sequences (I just let them fly over as they simply follow the laws of the physics) and instead of doing the animation the traditional way I have to define the forces, vectors and angles for moving the bones and the joints, therefore having a lot of mathematical work instead of artistic work (after all, I’m a programmer, not an artist, and when in doubt, stick with what you can, right?).

The only problem with the technique is that there isn’t really that much reference for me to look for. There are a lot of scientific papers written about it (just google for procedural animation) and some code as well, but since I haven’t (yet) found anything about it for Ogre or Ode, it seems like this will be my first test to see if I’ve learnt enough about the APIs to create a solution to a “real” problem. So in the next few days (weeks, months?) I’ll be going through the theory of procedural animation and try to come up with a way of combining the Ogre meshes with ODE joints and motors to create a real, dynamically animated character.

Yup, I’m still here. I’ve been going through some more of the Ogre tutorials and have reached the first intermediate ones. Things have been going well and I’ve understood the material, but the problems started when compiling the examples making use of CEGUI.

I mentioned before that using Ogre is designed to be highly modular with Ogre itself providing only the graphics engine. The Ogre tutorials also show how to implement a GUI functionality, which is basically required not only for the menus, but also for any kinds of 2D things you want to show as well as the mouse cursor. The tutorials use one of the few available GUI libraries, CEGUI (Crazy Eddie’s GUI), which is apparently also one of the most popular GUIs used with Ogre.

Using autotools, my first quest was finding out how to update my file in order to be able to include the CEGUI libraries as well as the Ogre interface for CEGUI. In the end, these lines were necessary to add:



Notice the name of the interface is CEGUI_OGRE (with an underscore), while the name of the actual library package is CEGUI-OGRE (with a minus). Using a minus instead of an underscore or vice versa made either my configure script or make to return error. I’m not sure if I did everything as I’m supposed to, but to me that was the only way to make progress. To me it sounds like a pretty bad naming convention, but if I see it wrong, feel free to correct me.

The first problem with the actual compilation I had was due to the fact that I had first compiled Ogre, and CEGUI afterwards. Big mistake, since Ogre has built-in interface for working with CEGUI, which is only compiled in if the Ogre configure script finds CEGUI, which of course was not the case for me. Browsing through the Ogre forums to figure out what went wrong, recompiling and reinstalling Ogre fixed that eventually.

The next problem was that while compiling Ogre code using CEGUI I kept getting the following error message:

/usr/local/lib/ undefined reference to `CEGUI::Exception
::Exception(CEGUI::String const&)’

Now, libCEGUIOgreRenderer is actually a part of Ogre, which apparently doesn’t play well with CEGUI. Huh? Sounds like a version mismatch, and after a lot of reconfiguring, recompiling and playing around I could finally make my code compile using not the newest stable CEGUI 0.6.0, but the older 0.5.0.

Note to self: when programming a library, especially when it will be used by other libraries, make sure the class interfaces stay the same from one version to the next. If I really need to redesign the classes, make it a jump from 1.0 to 2.0 (or 0.5.0 to 1.0) or a whole new library.

One might think it works now, but no, that would be a tad too optimistic. I could compile and run my program, but it would crash before actually showing the scene with the following message (delived by Ogre instead of make this time):

Texture: TaharezLook.tga: Loading 1 faces(PF_A8R8G8B8,256x256x1) with hardware
generated mipmaps from Image. Internal format is PF_A8R8G8B8,256x256x1.
terminate called after throwing an instance of ‘CEGUI::FileIOException’:

The error basically means CEGUI wanted to load some content (in this case, an image) but crashed while trying. Looking through the Ogre forums once again, I found a thread (
asc&highlight=ceguiconfig+xsd) advicing to compile in the use of TinyXML library instead of Xerces XML library when building CEGUI. Xerces is the standard XML library for CEGUI, but doesn’t seem to handle all resources that well. It’s actually pretty obvious when you think about it. You almost could’ve come up with that yourself. Lo and behold, after recompiling and reinstalling the code finally worked.

Conclusion: I didn’t really think getting Ogre and CEGUI (or anything, for that matter) up and running would be such a fight, but hey, it’s software, so it has to work somehow, right? And now that CEGUI actually works for me, it doesn’t actually seem that bad. I just make a mental note not to update it, at least not just yet. The building troubles seem to indicate CEGUI or the interface with Ogre is not all stable yet, but it does look promising to me. Luckily the user base for CEGUI with Ogre is large enough that a lot of the problems that do arise have already been discussed in the forums.

PS. In one of my moments of despair I also tried out another GUI library for Ogre, namely QuickGUI, hoping that this one would work better. In a nutshell, the guide for setting the library up told the programmer to make an instance of a class using a constructor that didn’t exist. Looking up the header files, the only constructor that did exist was protected. It was written in the comments that the class is actually a simpleton, although the means of accessing this simpleton was not documented anywhere as far as I could see (the standard getSimpleton() function was not there). Apparently the guide I was reading was for an older version, and the whole class design had been changed since then. I see that as another example showing the importance of design: design your library/application once, and design it well, so that you don’t need to change it afterwards.

So, this is the notorious first post to a blog. I hope it won’t be the last one as well (like in my last blog). I’ll just start by telling you what the blog is supposed to be all about. I’m a young computer enthusiast (also called “geek”) and I’m going to program a new computer game designed myself. In this blog I’m going to write all about my game and about the decisions I had to make while doing this game, so this is where 1. I should be looking when I forget why I wanted to do something like I’m doing, and 2. you can check if I’m still doing my game or if I’m vanished somewhere and turned my creation to another piece of vaporware.

Probably the next question for the reader is, what’s this game going to be all about. Well, it’s going to be a soccer (association football) game. How boring, I hear you say. I’m making a soccer game simply because there isn’t any other soccer game that I’d like to play. I want my soccer game to be huge, with tons of leagues and depth (like the good ol’ Sensible World of Soccer), be fun and easy to play and offer you a realistic, thoroughly simulated soccer with an impressive, creative AI. I also want my soccer game to be free software, open source, available for Linux. And since I haven’t found a soccer game like that, I’ll be making one on my free time.

“Oh, this is one of those free software freaks,” I hear someone whisper in the background. I admit that I’m very much into free software, and that free software is also a motivation for me. I’ve developed games by myself before, and still a couple of years ago I was doing that in Windows. Back then I had no idea what the free software fuss was about, and my problem was that everything I wanted to do had been more or less done before. You can’t find the soccer game I’m imagining for Windows, but you get pretty close, and that was good enough for me; I was playing games instead of programming them. Then I switched to Linux and bid my games farewell, my new hobby was figuring out how Linux works (and boy, that was fun). Now, I’m starting to miss gaming a bit again. As we all probably know, there really aren’t that many good games available for Linux, yet I refuse to boot to Windows or use Wine to play games. It’s not only because of Windows as a platform is not ideal or because with Wine most of the games I’ve tried don’t work, it’s also because the games aren’t free (needless to say, I mean free as in freedom). So, I’ll program my game in Linux, for Linux, I’ll make it free and open source, and because I know that there are people who actually miss good games in Linux, my work wouldn’t be in vain.

That is, my work won’t be in vain IF the game gets done and is playable.

I’ll go a bit to the technical details about the game now. The working title is “Free Kick”. Clever, huh. I’ll be programming it in C++, though I also considered other languages as well (namely C, Python, or the two for me unknown languages D or Eiffel). I chose C++ over the other languages because object oriented programming probably makes a big project such as this easier to manage (even if it’s not necessarily my favorite), because of the documentation, APIs, engines and tutorials available and because the step of learning a language like Eiffel or D (which I’ve heard they would be superior to C++ in quite a few areas) with the relatively small amount of documentation is at the moment too big for me to take.

I actually already have some code for the game. In the past few weeks I’ve programmed the basics about the game, but it looks way too shabby and doesn’t really work that well, so I’ll just skip the screenshot. I was programming something about the players a few days ago and noticed I was planning to do stuff like vectors and collision detection, where it hit me that it had actually all been done before (I’m pretty naive, at least when it comes to game development). So I went searching for an open source physics/graphics engine to suit my needs. I had been programming my game with SDL until now and thought it would be enough to be the only library I need, but thinking about the physics and graphics I wanted my game to have made me think otherwise.

So I went to check out the latest engines I could use for my game and the first thing I stumbled upon was Irrlicht. ( It seemed like a very good engine (and still does), but I went on a bit further down the net and the next thing I found was OGRE3D. ( For me, as an outsider without a clue, I spotted the following differences between the two libraries:

– Irrlicht has some physics simulation, while the users of Ogre rather rely on an external physics engine that they plug in and use with Ogre. This can be done with Irrlicht as well, but Ogre was specifically designed to integrate with other libraries.

– Irrlicht is, based on the first look, simpler to use. It is quite compact, wants to keep things simple, while Ogre offers more features and extensibility, having a slightly steeper learning curve. (This is also what they said in a thread on Irrlicht forums, for which I don’t have the URL.)

– Ogre uses LGPL as a licence, Irrlicht has Zlib. This means a lot of people choose Irrlicht because they are developing a commercial game and make changes to the engine, but don’t want to contribute their changes to the community. If you modify Ogre and release the modified version of it with your game, you have to release the source code changes you made.

At first, I saw the first point as a strong plus for Irrlicht. I thought I only need basic physics (it’s only soccer, after all), and seeing Irrlicht have integrated collision detection made me quite happy, after the horror story of half-implementing that by myself a few years back. The second point was also something that made me rather want Irrlicht instead of Ogre. This is the first graphics engine I’ll be using (since my QuakeC days, but that doesn’t really count), I thought, I should start with the easier stuff. As for the third point, it didn’t really make a difference for me, though I was surprised how happy some people at the Irrlicht forums were for the engine not being GPL’d and how it’s even listed as a feature of Irrlicht.

Yet, in the end I went for Ogre. Why? Well, I tried out a couple of examples of Irrlicht, and it didn’t really impress me. Well, the graphics did, it looked nice, even if OpenGL 1.5 sounds a bit old, but I realized the included physics were really quite basic and I’d have to go through integrating another library as well, just like with Ogre. Furthermore, my impression was that Irrlicht isn’t really as modular and extensible as Ogre, which seems to be built on the idea that everything can be plugged in and out. I still wasn’t quite sure about which library to take, so I looked at the tutorials section of both parties and went through a couple of them. The tutorials of Irrlicht were very easy to understand, very compact, and I found it very positive how easy things were made in Irrlicht. With the Ogre tutorials I was impressed by the amount of information. The tutorials build up from the very basics and go up to the advanced topics explaining everything on the way, making the material a lot to read but easy to learn.

I’ve taken the easy way down the road quite often, but here I had the feeling it wouldn’t bring me so much in the end. So I went for Ogre, even though Irrlicht was also very tempting, with the attitude of spending quite a lot of time learning to use the engine (and the other engines I’ll be integrating with Ogre). I’ve gone through a couple of the first tutorials by now and I’m very impressed. As I’ve often made the mistake of skipping a lot of the learning material of APIs or languages and tried to program my own thing (just to come crawling back to the tutorials later), I’ll be spending some time now just learning to actually use Ogre, instead of starting to program Free Kick with it.

So that was the first post of this blog. Actually I just wanted to tell you about me making the game, plus the “why” and the first “how” about it. I guess I accomplished that. I’ll be writing some more about my project in a few days (hopefully), so stay tuned.