Last time on Quest to Linux, I went through porting the Vigilante Game Framework to Linux, but the quest isn’t over yet. The next big task is porting Gemstone Keeper’s level generator and editor, the GenLevelTools, since I need to be able to get the caverns from somewhere.
GenLevelTools, aka the Procedural Level Editor, is a tool/library set that enables proceudrally generated grid-based levels to be modified and previewed in a level and used in games, while independent from any specific game engine or renderer. It was originally developed for my University Thesis on Procedural Level Generation and I later did a talk about it at the International Roguelike Developer Conference in Nottingham. The library is written in C++, so language specific quirks like forward slashes and for loops apply, so the main challenge this time around is the level editor, which uses Allegro 5 as well as the GUI library GWEN.
Allegro 5 is a C framework, although you can still use it for C++. Fortunately like SFML, it’s easy to set up for Linux since it’s part of one of Ubuntu’s repositiories. GWEN is a GUI library that was developed by Garry Newman (of Garry’s Mod). It was the easiest to set up for Windows but I had a few problems with the Linux version, as the gmake scripts rely on finding certain libraries and ending the entire scripts if those libraries cannot be found. This is different from running the scripts for Windows, which create Visual Studio projects that you can apply the libraries yourself. After tweaking the scripts and the source files a bit, I managed to get the GWEN and GWEN Allegro Renderer to build.
Aside from the main changes that I mentioned in the last post (using correct slashes, for loops) there weren’t that many changes I needed to make. I did have to add a lot more include statements, since despite being standard library stuff, GCC doesn’t immediately know what functions like memset, modf, floorf or ceilf among others off the bat, unlike Microsoft Visual Studio. After all these changes the library was able to compile smoothly. To make absolutely sure that it works within Linux, I wanted to build and run the editor, hence why I wanted to set up Allegro and GWEN. I managed to compile it with little effort, but something went wrong…
The editor crashed almost immediately, and the only reason I was able to show the following above was because I tried running the editor without the GWEN GUI rendering in the scene. It didn’t help that Code::Blocks debugger wasn’t working initially, and the closest I got as an error was below.
Fortunately I was able to configure Code::Blocks debugger to work, and was able to find the route cause of the crash being from the GWEN Allegro Renderer being unable to load the font, which is odd because the font I used (Lucida Sans) was able to load fine in my editor code, but fortunately GWEN provides an open source font (Open Sans) that runs just fine. So now with the GUI render up and running, I can test the editor!
I’ve been able to compile the library as both a binary and static build, as well as the editor. I could also compile the unit testing and C# wrapper for it too, but since I mainly wanted to get this done for Gemstone Keeper, I’ll leave it like this for now. Time for the main course!
GAMEPOPPER 
Pingback: Gemstone Keeper – Quest to Linux Part 3 – Gemstone Keeper | GAMEPOPPER
“since despite being standard library stuff, GCC doesn’t immediately know what functions like memset, modf, floorf or ceilf among others off the bat, unlike Microsoft Visual Studio”
Eh, yeah, the thing is, the C and C++ standards make having the includes there mandatory. Strictly speaking, Visual Studio is too lax there. In fact, MSVC is quite lax in a lot of ways, which often makes getting code written for MSVC compile on other compilers a chore (been there, done that). Another example would be the extra “Foobar::” in class Foobar { void Foobar::something(); };, which MSVC eats without complaining but is against the standard (and both gcc and clang die there).
It’s, in a way, trading away standards compliance in favour of comfort. YMMV on what’s the better way. Me, personally, I like to stay as close to the standard as possible.
For some of those functions, gcc at least used to only warn but still continue compiling. Might be a newer version changed that and now it directly throws a warning, dunno.
I guess for someone who is starting out with C/C++ programming, being relaxed is ideal. However as someone who hasn’t used a non-Visual C++ compiler on a large scale project, it does bother me that MSVC didn’t tell me. I wonder if there is/should be an option to set the level of standards used?
Pingback: New Years Resolutions | GAMEPOPPER