Few days ago I’ve pushed a new release of voxeliq v0.2.

It contains major improvements over the last year’s version;

  • More code cleanup & bug-fixes.
  • Improved mesh optimization (http://blog.int6.org/development/voxeliq-engine/improved-mesh-optimization/)
  • Added unit tests for engine.
  • Implemented a basic & buggy console & commands subsystem.
  • Implemented a very primitive blocky sky & clouds.
  • Improved logging & configuration facilities.
  • Implemented platform manager that can identify running platform & frameworks.
  • Added vsync & fixed timesteps options to config.ini.
  • Log targets are now also configured in config.ini now.
  • Added an engine.log file log-target.
  • Fixed a bug where chunks in cache-range were not lightened as expected.
  • Added cache-range checks.
  • Improved Chunk’s and Block’s string representation.
  • Fixed issue #18 where view-range value was incorrectly used when calculating cache width and height. Instead cache-range had to be used and fixed so.
  • Fixed Chunk.FastSetBlockAt() so that minus world coordinates also work. ChunkCache.GetChunk is also fixed for minus values. Player is now spawned at 0,0.
  • Moved chunk statistics calculation to ChunkCache.Draw() – finally the values are preserved, which eventually fixes the chunk debug graph bugs.
  • Added chunk removal queue debug-graph.
  • Fixed a tiny capture mouse & mouse visibility bug.
  • Moved ini-file based config-classes from Engine to Client project. Engine is now free of both Nini reference and the ini file itself. The actual game can do what-ever he wants when he supplies parameters to EngineConfig.
  • The Engine ctor() will now throw an exception when additional instances created (Discussed in issue #43).

Though being a major step with new functionality, I decided to abandon the code base and moved it to /contrib.

But why?

  • Because it just started as a hack & slash project as mooege, growth unintentionally.
  • It was primarily a hack to learn to cook block based games.  So did I. But the code growth every day with every feature I tried out and eventually become bloatware.
  • I started to develop it with XNA and then ported major parts to MonoGame. Still it’s quite hard to maintain both of them together. I’ll be just targeting MonoGame from now on as XNA is already dead.
  • I invented some freaking bugs which initially didn’t exist. I’m already too late to go backwards through commit history to hunt them. As the code uses every bit of available optimizations to improve the performance, you really need practice test driven development which current code base doesn’t.


I already moved the old codebase to /contrib and got some clean space there. I’ll be slowly porting / re-implementing the old-code from scratch – this time with proper tests. So probably until a short time, I won’t be able to publish cool looking screenshots of new features but once I’m all done, I hope to have a clean block-engine code base which I hope that people will find interesting & start contributing. And yes, I’m eager to port it to every platform that MonoGame supports, including Ouya!

So MonoGame is a great technology that allows us write common C# code and deploy our games to Windows-Desktop,  Windows-Metro, Windows-Phone, MacOS, Linux, IOS, Android, Ouya and even more. Being able to write portable code is great for us indie developers, though still your code may need some platform specific parts.

With our latest game Frenzied (which can run on Windows, Windows-Metro, Windows Phone 7, Windows Phone 8, Android, MacOS and Linux atm), we introduced our in-house platform-managment concept which we decided to blog about, so that others can also utilize.

Here’s how we are managing multiple-platforms for Frenzied;

First of all we created per-platform solution files;

Solution Files

Each project defines it’s own conditional compilation symbols so we can distinguish them;

Conditional Symbols

Then we defined some enums, the first one is Platforms;

GraphicsAPI enum;

Frameworks enums;

Then we implemented our static PlatformManager class, that will be responsible for identifying current platform and running appropriate code.

To get PlatformManager working we have to make two basic calls, the PlatformManager.Startup() and PlatformManager.Initialize(). Startup() call should be made from Program.cs for platforms that have a Main() entrance point where you run the game.

And in Game.cs (or what-ever you call the Game class) within Initialize() function you have to call PlatformManager.Initialize().

So PlatformManager will be doing all the hard-work for us. Note that how we handle it specific PlatformHandler and PlatformHelpers instances for each platform.

PlatformHandler is the base class that we can extend to implement our platform specific initialization code and so;

Note the PlatformConfig field that allows us to use platform-specific configuration. So you can for example enable mouse for a platform and disable it for mobiles.

PlatformHelper is the base class that we can extend to implement common functionality that needs platform specific code. The best example that comes our mind probably is launching default web-browser.

Let’s start implementing our handlers and helpers for each platforms;



 Windows Phone 7

 Windows Phone 8





That’s all! Now we can;

  • Manage our target platforms all together and have seperate platform specific code.
  • Have platform specific configuration (ie, hiding the mouse for specific platforms).
  • Have platform specific code to run behind scenes to implement common functionality (like opening a given URI in default web-browser).

I hope you enjoyed the article, if so please spread/tweet the word 🙂 If you have any questions please don’t hesitate to send a comment!

Note: I did not implement PlatformHelpers for IOS, Android, MacOS, Linux yet but should be pretty easy to do so!

We have decided to use the awesome gource to visualize the history of MonoGame‘s github repository and the output is fascinating!

So here is how we did;

Step 1 – fetching avatars

To download available avatars for commiters, we used the gravatar script provided in gource’s related wiki page.

 Step 2 – run the gource over git repository

Step 3 – render the video with ffmpeg



As you may know the popular gaming stream service own3d.tv decided to cease it’s operations.

So we have just released v0.51 update for eggrr which removes the own3d.tv support completely. It was also a good opportunity to push the favorites feature that was waiting in source repository.

As you can see in the screenshot below, you can now mark games & streams as featured.

eggrr 0.51

Here’s the full change-log of the update;


  • Added support for favorites feature – you can favorite games & streams!
  • Favorites feature will use roaming profile so your favorites will be available on your all computers.
  • Improved visual styles & look.
  • Removed own3d.tv support as the service is closed. RIP own3d.tv!
  • Improved app-bar button’s styles.

Go grab eggrr from Windows 8 app-store.