So recently I’ve been working on trying to smooth out some issues pertaining to how files are loaded and Chunks work, and I’ve been redoing a lot of backend things dealing with all of that. One of those changes was the inclusion of FutureChunks, which is (in theory) going to replace all the null chunk checks. Currently, they cause the main thread to stall due to them being hastily thrown together and not at all optimized, but I opened an issue on the Github for it and I plan to fix all the issues dealing with it soon.
Next major change was how Chunk loading/saving works. I originally just dumped the data into an output stream and force read it back, and it was bulky and slow and took up a lot of space on disk for not a lot of gain. I trimmed up a lot of the fat (aka removed the unused blocklight storage) and rewrote the loading/saving code to use the NBT file format. This also means that the old worlds will no longer work, but there is a noticeable speed increase loading and saving things, so that’s a plus. There is, however, a caveat with this. I had to extend the NBT format to deal with the Block array Voxel uses (Voxel stores some simple BlockMetadata, like rotation, with the Block ID in a long instead of an int), so all the current Minecraft NBT tools WILL NOT WORK with Voxel NBT files.
However, fear not. There is a new repo on the Lux Vacuos github, PyNBT. This is going to be modified to work with the Voxel NBT files from here on out. It runs on Python, and should be used as the basis for any implementations to use or to modify existing NBT utilities.
Heya, I’m HACKhalo2, the on again/off again secondary coder for Voxel (mostly due to real life issues sapping any energy I have). I’m going to be around doing things and stuff behind the scenes, helping Guerra as much as I can and trying to make Voxel the best it can be. Anyways, to the good bits of this Post.
Over the last couple of days, Guerra and I were banging our heads together trying to figure out why in the everloving hell Voxel was working flawlessly on his computer, but wasn’t working at all on mine. We both have different OS’s and hardware, which is great when developing a game. It also sucks a whole lot of golf balls through garden hoses when a bug like this pops up. And it was literally the dumbest bug there could be, that shouldn’t of broken everything, but it did.
In the F_Tessellator shader file, line 26, is a vec3. That vec3 used to be a vec4, and that vec4 broke the Tessellator for literally every system and every OS, except systems using nVidia GPUs. Why was nVidia spared from this horridly stupid bug, you might ask? There are two ‘theories’:
- nVidia is lax on it’s GLSL spec compliance. It allowed a vec4 to be incorrectly used as a vec3.
- nVidia is lazy as the Duck Hunt Dog and just likes to laugh at you while you waste hours tracking down stupid bugs that should be throwing parser errors anyways.
There was also an GLSL extension Voxel was using that was nVidia specific (or at least only currently implemented on the GeForce drivers), ARB_shading_language_include, that loved to completely crash the JVM if used outside it’s little safe space. I wrote a co-preprocessor, the ISL (Includes Shading Language), to mimic and extend this behaviour for Voxel so all platforms can benefit from it. There are plans to extend the ISL farther to make Voxel’s GLSL shaders more dynamic, but that’s down the line. I’ll make a blog post about the ISL next week sometime.
That’s all for today! Until next time.
Happy New Year to everyone!!
First, the accounts server is in an undefined maintenance so logins through the launcher are disabled, we are looking for a new account system or making a custom one.
And on Voxel
- Voxel has received a new World System with new subsystems, all written from the ground with Multi-Threading in mind. The first test were good, minor issues where detected and fixed but apart from that nothing new.
A bug that affects all OS X systems was detected which is in progress of begin fixed, this bug causes the Tessellator to not be rendered so the world is invisible, still there but can’t be seen. Fixed 😀
- The new Molten API will work using scripts, mods are now be done using scripts. This will made mods easy to port from the Client to the Server, also the server can sync mods with the Client easily.
More info about this in the coming weeks.