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 freakingbugs 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.

So?

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!

We have been lately working a lot on the Voxeliq Engine and thought it’s about time to push an update;

Possibly the quite exiting change lately is the improved mesh optimization support. Actually this was nothing new and meshes were already optimized but for every set-block operation you had to include ugly piece of code to get the optimization working;

I was working on basic tree generation last few days which allowed me to discover a sneaky bug in block texturing. While applying textures for blocks, textures of all but top faces were applied correctly. Though as I was mostly using homogeneous textures for testing purposes (rock, sand, grass) it was really not possible to see the problem.

It was the non-homogeneous tree-top face texture that revelead it. So I dig deeper in texture-UV mapping code and it wasn’t really easy to spot the actual bug. I further decided to roll back my changes through git to see
the commit that introduced — to my surprise it was a really really sneaky, old bug which even existed in very first git commit (that I moved the project from bitbucket to github). As I had deleted the bitbucker project and didn’t have earlier history backed up, it wasn’t possible to track it back.

So there was nothing left but to verify all uv-mapping code. Few hours later I spotted it at last; wrong uv-mapping indexes were applied for Y-increasing faces!

There we go! I had just fixed a major sneaky bug that was lurking in git repository for a long while and it really really feels good to fix one!

If you aren’t aware yet, those great guys over Mono project works on creating an OpenGL based implementation of XNA framework which can target MacOS, Linux, Android and IOS (those latter two of course will require MonoDroid and MonoTouch). So their website already mentions the ever first 3d game powered by MonoGame and I couldn’t resist giving it a try to get Voxeliq running over MonoGame! Here goes the story;

It took me a few hours to figure things out. At the very first I tried my chances on wrong branch – MonoGame/develop – which at the time being is the furthest branch. Though I got my answer on irc.gnome.org #monogame, which ‘develop’ did not have support for MojoShader – which allows HLSL shaders to run over GL (it converts them actually).

So I checked out the develop3d branch as mentioned in irc channel, which was the correct branch to go for 3d games. Within my initial try, I got lots of error messages from compiler complaining about missing HalfVector2.cs. So I put in the XNA implementation, fixed a few bits here and there and all the errors were gone! When I hit run button, things started up but I got an exception where MonoGame was complaining about threaded creation of GPU resources were not supported yet (which will be fixed later). Bingo! It was all okay and I was able to run Voxeliq over MonoGame using OpenGL. So Voxeliq is not the first 3d game/engine running over MonoGame but I guess it’s one of the very earliest ones

Oh and I had to disable few bits / components (bloom effect, my music manager implementation and console which uses Digital Rune libraries that was compiled against XNA4) of Voxeliq which may need fixes – though that’s for another story I’ll be updating you guys on the progress.

Even better there are still more rooms for optimization which I’ll be working on them until I get a perfect point. Here’s a speed demonstration video. Note that in video there exists nearly ~960 chunks and ~30 million blocks.

In one of my previous DevLog entries I had mentioned that I was switching to a single huge block array technique instead of array per chunk which eventually simplifies access to block data. Now I’m done with upgrading my lighting code to take advantage of new block array technique and results are great!

With the latest updates, ligthing is now 3.2 times faster! Wow, that’s a really great optimization which worth every single seconds I’ve worked for it! Here’s test results;

First, the old technique was optimized for old block array per chunk storage. So within this to access a neighboring block, it had to access using chunks – as a neighbor block could be in another chunk. The below propagation functions first need to resolve the chunk that owns the asked block (as block arrays are per chunk) and then need to progress on.

So basically, Microsoft doesn’t give a single word on future of XNA especially when you think about it within upcoming Windows 8’s context. There are two different views over people’s blogs where few of them claims that XNA reached end of it’s life where others claim that next big XNA update will be coming with new Xbox.

So I dived further in. First I’ve installed Visual Studio 11 Beta, just to see it does not support XNA projects anymore. So at least for now forget about upgrading to VS 11 Beta if you’re still developing for XNA – and I’m really not sure if Visual Studio 2010 will support targeting .Net 4.5 but I hope so.

Only partial Windows 8 marketplace support, i.e. Marketplace will only provide a web link to an installer that you must host yourself and (as yet) there are many unknowns about handling transactions and security.

XNA apps will run on x86 and x64 but not ARM processors.

You can reuse your code between XBox360, Windows 7/8 and Windows Phone 7

Unknown whether XNA apps will run on Windows Phone Tango/Apollo

Voxeliq’s future
So basically Voxeliq owns a huge codebase which I don’t have any willing/time to port native C++/DirectX any soon. So I’ll be staying within lands of mysterious C# game development. Options available are;

I’ve previously played with slimdx a lot but the bad news is that it doesn’t support upcoming DirectX 11.1 or Windows 8 Platform and it really lacks a sample game framework which I had to implement on my own (too bad I deleted the sources thinking I would never need it!).

SharpDX on the other hand is ready for DirectX 11.1 and Windows 8 platform already. Even better, there’s a good game framework sample itself – the ANX framework which is actually based on SharpDX.

So I guess I’ll be taking SharpDX way though will not be starting to port my code any near before we can get more detailed info on what’s going with XNA.

So, in this kinda blog page, I’ll be also trying to comment on language & framework other than talking about my stuff. With the latest huge array technique with flatten array support, I do now use block pointer functions and here’s one;

All code in the engine that access block data has to use one of these functions and it’s really not a good idea to repeat the code all over the source (given that a possible future update on functions will require lots of time and will make it harder to maintain and hunt for bugs). Although today’s modern compilers are quite intelligent, still I was eager for some forced inlining functionality given that those functions get calls millions of times. Statement lambdas are a possibility but they’re technically not what I’m looking for;