# This Time, some Real Computer Achievement

Contrarily to how easy it was to set up my Joystick the other day, yesterday and today I have been busy with the laptop I name ‘Klystron’ that actually required some computer-skills on my part.

It was a subject of mine for a long time, how 3D Game Design works, and in particular, how the raster-based DirectX or OpenGL rendering works. To study that subject in my private time, I have always maintained a set of programs, that would in theory enable me to create a game.

In practice, creating any game decent enough to play, requires oodles of time and work. But I always felt that the software-tools involved should belong to my collection, even if I do not really put them to thorough use.

One software tools I have been pursuing, is the graphics rendering engine called “OGRE“. For several years I have been trying to custom-compile OGRE 1.10, just because that version offers better support for OpenGL 3, which should give game authors access to Geometry Shaders. But as it happens, I have ‘Mesa‘ drivers installed on that laptop, that do claim to create support for OpenGL 3, but that oddly, do not go so far as to offer Geometry Shaders. This is not a fault of the OGRE development team.

Also, there are reasons for which I do not simply ditch the Mesa drivers for ‘fglrx‘, the latter of which would give me OpenGL 4: I find it important enough, that the Mesa drivers allow hardware-acceleration of regular, high-def, 2D video streams. I would not want a real video stream / movie to become a burden to my CPU, and the fglrx do not GPU-accelerate that. So I stick with the Mesa drivers.

But then there was only one good way to get my OGRE install stable. I had to switch the Mercurial version of it I was subscribing to, down to OGRE 1.9, which is highly stable. The only issue with that remains, that OGRE 1.10 would have been my only game engine, which would have ever offered me full OpenGL 3. Which was just not stable on that box.

Now that the OGRE version on ‘Klystron’ is a sensible 1.9, that also means the engine has no extreme advantage over other game engines I possess. They all tend to be of the vanilla variety, that offer OpenGL 2 / DirectX 9c… – GL 3 would be equivalent to Dx 10, and GL equivalent to Dx 11.

Speaking of vanilla, I also installed the latest snapshot of Crystal Space on ‘Klystron': Version 2.1 ! I am amazed at how much better this latest build of Crystal Space seems, in terms of being stable when compiled, than earlier builds of it were.

But then on one coming day, I will also need to put Crystal Space 2.1 through some actual testing – like maybe, just to try all the demos that come with it? And on that subject, Crystal Space uses ‘CEGUI‘ for its UI, which OGRE has not done in ages, and I spent the better part of my day fidgeting with CEGUI 0.7.6, just because that version comes from the package manager. I was able to custom-compile CEGUI 0.8.5, and then the advantage would have been automatic Python support. But it just so happens, that Crystal Space would not recognize the custom-compiled CEGUI, only the one installed from the package manager.

And then, one real drawback to the package-manager version of CEGUI was, the absence of the fitting PyCEGUI package. Really, in order to create CEGUI panels, one needs a graphical layout editor for it, and this requires PyCEGUI.

And so what I finally did was to download CEGUI 0.7.6 from source-code, to match the version string of what I had installed from the package manager, and then I managed to configure and compile it in such a way, that the custom-compiled version did not really install itself, but from which I only installed the Python bindings.

This latter task required, that I also use manufactured ‘Makefiles‘ as a template, and I modified the Makefiles to do what I needed. ( :1 )

So the layout manager ‘CEED 0.8.0‘, which needs PyCEGUI, was also the first graphical output, which Crystal Space 2.1 greeted me with today. I was so busy just adjusting code all day, I really got no graphical work done.

Dirk

BTW: I also hold licenses to certain affordable, but paid-for game engines. But then I hesitate to make those a blogging subject, because I try to avoid making product endorsements.

(Edit 07/26/2017 : ) I should add that one fact which added to my workload in the past two days, was that ‘Crystal Space‘ is not one single package. Like ‘OGRE‘, ‘CS‘ is a library which only concerns itself with the actual rendering of 3D Models, including the so-called “convex models” that make up a scene, including light-sources and fog, but which would all need to have C++ programs that control the details of what and how to render. This leaves out any possibility that these models form ‘Game Entities’.

To go with Crystal Space, there is an added package called ‘Crystal Entity Layer‘, or ‘CEL‘, which allows for the 3D models to be grouped into Entities, such that those entities become actors, to which simpler Actions can be attached. Actions are executed differently from C++ function calls / subroutines, in that Actions run concurrently, and have their own API, for accessing attributes of these Entities, that would be relevant to actual game design. Also, an Entity abstraction running for one Entity can ‘listen’ for the (ranged) presence of other Entities, and finally allows them to have robot-like behavior, as though each Entity only had its local information about the game level.

The Entity API is usually simpler than actual C++, which would control the rendering engine. Yet, with ‘CS‘, the Entity Layer itself is also programmed in C++.

Even if a programmer was to use OGRE in an effort to create a game, he would still need to supply some mechanism himself to provide this, as OGRE is not by itself entirely a game engine – only being a rendering engine.

Thus, yesterday I also compiled Crystal Entity Layer to go with Crystal Space, and I also compiled ‘Crystal Space Editor‘, which will supposedly allow for editing of potential game content, from within a scene that runs within CS for this purpose… I have yet to find out how well all that works.

But then it is still on my list of to-dos, to add Blender add-ons that I would eventually need, to design CS content using Blender, which is The Major 3D Model Editor for use with Linux. I also already have a few other, paid-for model editors, but the essence of my projects is an open-source ‘eat your own dog-food’ theme.

1: ) The task has confronted many CEGUI users, that they have installed CEGUI from the package manager, but need PyCEGUI as well. The standard solution to this problem, is to throw that out, and to custom-compile CEGUI, with Python bindings. But in my case this did not seem feasible, because Crystal Space only recognized package-installed CEGUI. I did not make the attempt, to set the ‘prefix‘ of the custom-compiled CEGUI from ‘/usr/local‘, to ‘/usr‘, which might also have worked.

My solution in this case took advantage of the fact, that a tree of recursive Makefiles puts a Makefile into each sub-directory, such that there is also one in the sub-directory for the Python bindings. This means that if we have compiled CEGUI successfully, it should also be possible in principle, just to go to that sub-directory and to run ‘make install‘ as user root, only in that sub-directory.

But my case was not so cooperating again, in that on my box, CEGUI 0.7.6 failed to compile – even though the packaged version was compiled by somebody else. And so I needed to ‘./configure‘ the project, which put the Makefiles into all the sub-directories, then to navigate to the sub-directory for the Python bindings, and only to run ‘make‘ on that sub-directory…

What that will do, is tell the source-code for the Python only to use the header files that belong to CEGUI 0.7.6 in my case, to compile all the PyCEGUI object files. But then in my case, just as it would be for anybody else, a link-up with the static libraries needs to take place, which in this case have not been built, thus producing an error message…

At that point, I edited the Makefile that sources PyCEGUI, to change the prefix encoded into the Makefile, and then to edit the Makefile in the sub-sub-directory, where the output libraries are to be linked, to look for the CEGUI static libraries under ‘/usr/lib‘ as well, instead of looking for those within the CEGUI project folders, since they were not to be found within the project folders, since they could not be built.

Such editing of a Makefile is delicate and risks running into errors, but I was able to find only the pieces of the file that needed to be edited, and to do so without error.

Then, an added advantage to this approach is, better matching with the static libraries. It is always important that the Python bindings find an exact match, with the installed library version, and even if I had compiled the latter using a source tree with the exact version string, some mismatches with the packaged version libraries would still have been possible. But this way, the same static libraries were linked – there were two required – that were also installed from the package manager, and, the output libraries had been told to link to them under ‘/usr/lib‘ and not to go looking for them under ‘/usr/local/lib‘, the latter of which is where custom-compiled libraries are usually installed.

Also, I expect the project header files to match exactly, as long as the version string does. Those header files produce PyCEGUI object files from the relevant source files, thus ridding the situation of the last possible source of error. Further, both project versions were configured to allow OpenGL-based rendering, as well as OGRE-based rendering, which allowed for both required static libraries to be installed via package manager, and to be correct.

Actually, the header files can expand into different meanings, due to project settings. And I understand why I was having most of my compiler issues with the older source-packages. My ‘wx’ headers are for ‘wx 3.0′, while the older projects expect wx 2.8 or 2.9 . This causes some mismatches in what needs to be declared, in any source files that use ‘wx’.

Simply telling my whole project to use the prefix '/usr', not ‘/usr/local‘, struck me as too dangerous, since I could later have given the command to install that whole project accidentally, even though everything was already package-installed.

I find it important, not to use CEGUI in any future OGRE projects, because the package-manager version of CEGUI links to the package-manager version of OGRE-libraries 1.8, while my custom-compiled, ‘correct’ OGRE version is 1.9 . If I did use CEGUI, thus not from Crystal Space, doing so would cause both the v1.8 and v1.9 OGRE libraries to load, which in turn would cause a guaranteed mess. But, since Crystal Space never uses OGRE libraries itself, and is also the only client from which I plan to use CEGUI, then to have OGRE libraries v1.8 load with it, should pose no problems.

## One thought on “This Time, some Real Computer Achievement”

This site uses Akismet to reduce spam. Learn how your comment data is processed.