Here are some updates on my research and development.
First off, I have added a lot of controls to the Jewel menu system since I last wrote about it. I’ve added sub-menus and sliders, while also cleaning up the codebase. I concluded this would be much easier to program with C++, particularly for exception handling, which has always been a problem for C programmers like me. As such, I will probably be converting by the next release.
I’ve found rewriting CANINE from the ground up to be particularly frustrating, and haven’t spent as much time as I should have on it. I tried updating Alpha-2 to have the changes I was planning for the new version to see how that would work, but that has also been oddly difficult. It doesn’t help that I have so many other things I want to do, too.
However, I have progress on the scripting language compiler! I wrote it in Ruby to allow for rapid prototyping and it is all hand-made. It supports a tied file-module structure (each file is a module) with module-level fields and functions. Good support for arithmetic, conditions and function calls has been implemented, though there are no control structures. The resulting output is in a human-readable assembly-like pseudo-code so that I can debug the compiler. This project has been rather fun.
Download orangecc.rb here. (GPLv3+ as well.)
What has caught my interest lately is voxel-based engines like Minecraft. Though, I’d like to point out that the blocks themselves in most of these aren’t actually voxels, but they often refer to the blocks as voxels, which is unusual and can get a bit confusing. However, I have learned a lot about modern OpenGL programming (and real-time graphics in general).
The most useful thing I’ve learned about is vertex arrays. As opposed to making a function call for every single vertex in the world, you just make one given an array of all the vertices you want. This speeds things up massively, though it further displays the usefulness of C++ (creating those lists is easier with std::vector’s than manual malloc/realloc-arrays). You can bring it down even further by culling out (ignoring) faces that are blocked by other cubes.
What’s interesting about voxel-based engines is the way they implement this. The world’s always changing, so you can’t have a static, unchanging array of vertices. Instead, the list must be regenerated every time the world is modified. Of course, this would take way too long in a world as big as Minecraft’s, which is what makes chunk-based design so useful.
For those of you who don’t know, Minecraft-type engines separate their worlds into multiple 16x16x256 (numbers change between some versions) chunks of blocks. What most people know is that this allows parts of the world to be loaded and unloaded at will. Something that most people may not know is that this also allows each chunk to maintain a separate vertex array.
When you modify a chunk, only that chunk’s array is modified. This allows regeneration to occur in real-time while still bringing render-times down in orders of magnitude. All you have to do at this point is balance array regeneration against render speed to determine chunk size, which is a decision left up to the human.
I’m not particularly sure if this is how Minecraft does it, but it appears that this is how many voxel-based engines work. I know Minecraft uses chunks, I just don’t know if it generates vertex arrays and, if it does, if there’s anything more they do.
From all this information, I wrote my own little voxel test. I call it McCraft because I really didn’t feel like thinking up a fancy name and that was the first thing that came to my head. I built it with Allegro 5.0.9 (for input and graphics) and libNoise (for Perlin-noise height map generation).
Download McCraft here. (Again, GPLv3+.)
So that’s the news. Also check out the latest version of Pizazz which now supports alternative currencies!