Skip navigation

Monthly Archives: April 2008

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.