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
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
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
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.
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 ‘
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.
Entity API is usually simpler than actual C++, which would control the rendering engine. Yet, with ‘
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
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.