www.freakinabox.com

There has been a recent update to GCC, so naturally I updated my copy and set about recompiling the libraries I commonly use.

I then started getting some very odd out-of-memory errors coming out from ld. For those not in the know, ld is the ‘linker’ tool that takes all the compiled object files and links them into a final binary (EXE or DLL on Windows). It turns out that a change of functionality has come about in the latest version of GCC that has massively affected the size of the object files it produces. In basic terms, any inline dllexported function is now written to every object file that includes the header containing the function. While usually not much of a problem, compiling something like wxWidgets into a monolithic DLL now creates well over 2GB of object files.

The result of all of this is that either GCC needs to be patched with a switch to turn off this new functionality, or wxWidgets needs to be patched with some compiler-version specific workarounds. Not fun either way really.

EDIT: It’s been submitted to GCC’s bug tracker

And in a feat not seen since the last time I took time off work, I have completed the first part of my project. I now have a procedurally generated line. Oh the excitement is palpable!

All steps in the generation of a horizon line

The above montage demonstrates each step taken in the production of the resulting horizon line. Each step uses the same simple algorithm which is the whole point of content generation. Even using the terrible random number generator provided by the standard C++ libraries seeded with the current time can produce nicely different results. Another excellent point of procedurally generated content is that a better RNG gives a larger spread of results, while clamping the seed to a known value allows you to use the same simple small algorithm to reliably create large reproducible data sets; be that images, sounds, or meshes.

Horizon 1 Step 8

Horizon 2 Step 8

These two images show how with even a very small difference in seed on a very poor RNG, the differences are quite noticable.

With all my work being taken up on building SOGui recently, I realised that I was loosing sight of the work that spurred me back into programming in the first place, namely procedural generation.

In that regard, I have started on another project. This one will let me begin producing procedurally generated visuals without having to go through all the legwork of creating a suitable GUI by using wxWidgets, and only using OpenGL as a component for drawing, rather than as a full interface. As with all my projects, I’m aiming to keep it as portable as possible, and useing Code::Blocks and gcc to develop it.

Below you’ll find a screenshot of the app in it’s early stage.

Screenshot of Horizon App

This will be the first part of a suite of ‘generator’ apps, and is concerned with only 2D procedural generation. This means it will simply take a line, and continually chop it in half, adjust the middle part up or down, and then continue to run on the new lines generated from that. An explanation of the algorithm itself can be found on http://www.gameprogrammer.com/fractal.html#midpoint. It is incredibly simple for now, but it should give me something to get started, and a break from SOGui.

If you’re interested, the source can be found, as always, on github at http://github.com/TimJones/Generator.

Don’t look now, but I’ve actually started writing guides. The first one is simply a guide to get SVN Code::Blocks running under an Ubuntu system and available here. In time, I plan to add more for setting up MSys & MinGW on Windows and leading on to build environments for SOGui.

Please leave feedback.

After a massive drought of enthusiasm brought on by the endless issues with source dependencies that CEGUI needs I decided that I should begin from scratch with my own windowing system – something I wholly didn’t want to have to embark on.

Since making this decision, I have actually made quite a bit of progress. I have reverted back to trying my development closely to the SDL, including SDL_ttf (a TrueType fonts wrapper) and SDL_Image (handing the reading\writing of many image formats inc. loading them to textures).

I am still at the concept stage at this moment, but I have got several things sorted out, I have a FBO wrapper class to save an awful lot of time in building bits on top. I have a very basic window class to which I am adding input-handling and other bits as I go.

In the future, I plan to add a window manager class, through which you would actually make the windows etc… I also have to find a way to allow for user-drawn window decorations, pondering functors, inheritance, or something altogether more exotic. User-skinned windows are one of the lowest priorities, but I don’t want to work hard to produce a windowing system that has to be completely refactored to fit something like this in.

Still, I will release more information as I get further on with the coding, and it’s finally starting to look up.

Firstly, I must sincerely apologise for going more than a month without an update, though is is a technical blog and not a personal one so I will not bore you with details. Suffice to say my workload has expanded massively, certain things in my personal life have had to be reprioritised, and this has left me with precious little time for myself and my hobbyist pursuits.

Still, in the times I have not been in a vegetative state from exhaustion, I have been working on my little project. A game developer friend of mine suggested I might want to check out CEGUI,which is actually a component of the previously-mentioned Ogre engine. It is a rather high-level windowing system for either OpenGL or Direct3D. It’s nicely object-oriented and contains good bindings for SDL too. It allows some major theme skinning as well as window\widget design though XML files which introduces great flexibility, but also allows you to fall back on hard-coded windows if you don’t want to be messing around with resources.

It seems to be that CEGUI could well be the answer to my problems, but I have yet to actually be able to use it in any of my code. While they are fantastic in providing assistance through the forums, and provide the binary SDKs for every version of MS Visual C++ from 6.0 onwards, Mac OS X, and Linux build environments, there is no package for GCC under Windows. This means I have to get the source version, and all the dependencies (16 packages in all), and then build them each 4 times over (both debug and release each for static and shared builds). As you may expect, this takes a not inconsiderable amount of time, which is coincidentally, the one thing I have least of right now.

Right now then, working on my ‘project’ consists of mainly: once a week, downloading a package and building one (or two if I’m really lucky) of the bits I need, and marking it off the list. Though after having spoken to Crazy Eddie (Lead\Original developer of CEGUI), at least I can be safe in the fact that once I’ve got through all of this, the fruits of my labour will be hosted along side the other binary SDKs for the availability of other users. Who knows, maybe I can even get my name in a source file somwhere…

Until then, back to my build tree.

Sometimes I wonder if I’m cut out to do any programming what so ever. This evening while playing with tying SDL, Agar, and OpenGL all together, I spent an hour and a half tracking down a single errant close bracket.

It was not helped by the fact that SDL helpfully, and silently, re#defines your normal ‘main’ entry point into SDL_main so it can supersede yours with its own. Had I known that simple fact I would not have had to spend the time trawling through SDL header files completely doubting my own sanity in how such a bug could be left in library code.

Not only this, but earlier in the afternoon I spent an equally rediculous amount of time wondering why I suddenly couldn’t declare a bool any more. In my foolish haste to copy & paste example code to begin hacking away at it I failed to notice the source file had a .c extension rather than .cpp. Good old MIME getting in the way once again.

Yes, I will be handing back my membership card in at the door on my way out, but by root I’ll earn that damn thing back again!!

After some time playing with Agar (the only documentation being the API and a wiki full of stubs) I’m not sure any more if we will get on. Don’t get me wrong, it seems like a fully-functional library, but its idiosyncrasies don’t mesh with my own. It has a very C-heavy syntax with raw pointers all over the shop, I prefer C++ OOP structure with my pointers wrapped up safely in safe-pointer template objects. It also wants to be an independent library, or at least the ability to hook into many different frameworks. I would like a library tightly paired with the SDL as to not have to re-work any functionality already provided to me by it.

I will be continuing with it for the mean time, hoping that my increased familiarity with it will assuage my current misgivings. Failing that, I fear I might well have to embark on a much more trepidatious task than first realised…

I’ve been following the development of a project from UK indie game company Introversion. The project has been long running (two years and counting) and relies heavily on procedurally-generated content, that is, content created by an algorithm rather than an artist. The terrain, roads, blocks, buildings, even the internal building structure, lift space, staircases, and structure support, all generated on the fly when required. The project is called Subversion and has a link in the sidebar over there…

This project has, for some reason, single-handedly reignited my desire to program. To begin with, I simply wanted to clone Chris Daley’s work bit-by-bit, start of with a simple terrain generation, then move on from there. Then I saw this screenshot and it blew me away. It was no longer the method of creation, but also the simplistic but incredibly stylistic presentation.

I’ve always wanted to be able to work with a windowing system within OpenGL, but the available APIs I’ve used have failed to satisfy completely. FLTK is too flat, Ogre is overly complex, most others either just aren’t polished enough or are stretching too far… I’ve used Agar in the past, but not for some time. It looks to have made some major improvements in recent times, including a full skinning\theme system with the 1.3 release. To save myself some time and effort, I will attempt you see if Agar can be tweaked and teased into my expectations, but I will always be thinking of building a system from scratch specifically to solve my curious and self-challenging nature. Essentially, if Agar can be made to let me render to texture and use said texture as windows content then great. If it allows me to have multiple ‘rendering’ windows in separate threads and a robust event system, then I’m sold.

To handle the more mundane OS windowing system, I’ve used GLUT\freeGLUT in the past and never really felt them to be flexible, or functional enough to make them worth using rather than rolling my own. I’ve used SDL (link in the sidebar) an awful lot and found it be powerful, flexible, and best of all, pretty damn easy to use. What’s more it’s still actively developed, unlike GLUT (last updated to 3.7 in Aug ‘98). SDL also gives me cross-platform handling of threads and event signalling, without needing to rely on any extra libraries, again reducing complexity of the build. It also has extensions for sound, true-type fonts, and network stacks so it’s pretty fair to say that unless something really amazing shows up, I’ll be sticking with SDL.

Code::Blocks has always been a favourite IDE of mine, hooking in to all manner of compilers and quite a few interactive debuggers, plenty of features and extensibility whilst still maintaining a low running footprint. It hooks nicely into MinGW, the GNU build toolchain for Windows, but will also play well with MSVC if you want to use that.

To finish it all off I use Git for version control. It’s a fantastically quick & simple source control system, with no large overheads required of the client-server systems such as CVS and SVN. I’ve never had to use it in a massive development environment (but the Linux Kernel peeps don’t seem to have a problem) nor in a corporate setup, but for my purposes, nothing works as well.

So, it’s taken me a good day’s work just getting my build environment back up and running, and tomorrow won’t be time I have available to work on this, so it really will be a Long Term Project.