If you have been following me on Twitter, you may have noticed that after game jams, I’ve returned to Gemstone Keeper. Since I started work on my thesis project, GenLevelTools, I have been working in Allegro 5, using my previous experience and the already functional graphics rendering, for both the GenLevelTools and Gem Finder, the simple prototype that is now Gemstone Keeper.

However I decided that I would change the underlying framework from Allegro 5 to SFML 2, the thought of changing systems has been in consideration since IRDC 2015, which came about for numerous reasons:

• The Gem Finder code needed updating, as it was written during a time where I was under pressure to meet a deadline and have something to show, for what was essentially the most important part of my University degree. Now that I have graduated, and have gotten a full time job, I have a bit of flexibility and less pressure for me to make some improvements. If I was going to update the current code, I needed a framework that could satisfy the needs of a new system. I could rewrite the code with Allegro 5 with my experience and confidence behind me, but…
• Allegro 5 has limitations, which makes some of my concepts for Gemstone Keeper less feasible. The last stable build of Allegro was back in January, yet it lacks certain features that you’d find in other C++, C# and even Haxe frameworks. Specifically shader support for effects, and gamepad support beyond DirectInput. While shaders are a feature of Allegro 5’s unstable builds, there is the issue of stability and compatibility. My attempts to get the unstable builds to work have been less than futile, and even when I finally got a functional build of the unstable release, I was met with a lack of certain libraries to run shaders (namely libpng1_6.dll). It wasn’t worth it, and if it was a struggle for me to get it to work, then it would be worse for me to help get the game running for other people. Also Xbox 360 controllers are recognised as DirectInput devices, which does have some limitations, specifically with the analogue trigger buttons.

This is where SFML comes in. Like Allegro, SFML is a set of C++ libraries that can be used to develop games for PC, Mac and Linux with experimental Android and iOS ports. However, SFML does have shader support with little to no issues installing either the latest source code or direct download from their stable release. While neither have XInput Gamepad support directly, the SFML community have had no problems showing how easy it is to make an XInput wrapper for SFML.

The real seller for me is that SFML’s text rendering has a much superior output, but also support for wide literal characters. This is a big deal for anyone who is developing games that rely on text, such as games with ASCII graphics.

Firstly, Allegro’s text rendering seems to struggle with rendering text that isn’t a factor of two, or below a font size of eight. This is pretty reasonable for using TrueType Fonts that may not have data for all sizes, but software that uses a lot of text have algorithms that help keeps the quality of text consistent regardless of size. In my tests, SFML handles this quite well, while Allegro has issues such as lack of transparency and defects with certain characters at small sizes.

Left: Allegro build Right: SFML build

Secondly, being able to use wide literals means that I am no longer restricted to characters in the ASCII format, which have less than 255 usable characters, now I can use over 1000 possible characters in the Unicode format, which as of C++ 11 is fully compatible (SFML says that they don’t support unicode formats at the moment, but as long as the font supports them, SFML should render them!). This means more possible creative designs, so more enemies, environments and other features are possible!

Copyright symbols as enemies, because I can now!

Most importantly, SFML is being constantly updated, like I said earlier, the last stable release of Allegro 5 was back in January. In comparison, since starting the framework transition back in August, SFML has already had two updates for SFML 2. It also benefits that SFML is an active community, and appears to have more of a social media presence. These factors help in both finding framework issues, and possible advice for certain functionality.

The new framework I’ve been working on has a slightly different approach, more similar of an approach to Flixel, like what I did earlier with my MonoGame framework Ricoh2D. As such, I’m using an inheritance of a singular base class, as well as a heavy use of object pooling. This way I plan on having updating, rendering and collisions accessible for each object, to make it easier to add and remove objects at runtime. Like Ricoh2D, I’ve aimed to have collision checking handled on a single function call, with the option to pass in a function for collision response.

Because I’m using SFML, I’m also hoping to produce a more optimal and performance with the aide of VertexArrays. All renderable objects in SFML use Vertices to determine the coordinates, texture coordinates and colour of each point of a graphic. During development, I’ve found it is highly efficient to use VertexArrays whenever you can for more custom rendered objects, as there is some overhead whenever you perform a draw call, although the effect is larger in debug mode. For example, when I initially built a tilemap renderer that drew each tile as a separate sprite, I was getting around 400 FPS. When I changed it use a single VertexArray object, where each four vertices is a single tile, the framerate shot up to 1200 FPS. I have since used VertexArrays to replace SFML’s built-in text renderer with my own, that allows me to have text alignment combined with multi-line rendering, when the built-in renderer only had multi-lined text while aligned left. I am considering creating a sprite-based particle system using vertex arrays, as my current system uses multiple sprite objects.

As of writing, the transition of features from the Allegro version to SFML version of Gemstoke Keeper is around 75%, most of the basic rendering has been implemented, the level generation has been transferred over. I need to implement the current enemy behaviour as well as level progression and other enemy screens to have a complete transfer. Once that is finished, I should be able to work on my plans for new features, and should start planning on releases.