Skip navigation

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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: