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