This side-project of Voxel, Light Engine and Lux Vacuos just when downhill after mid 2017. What I can say about them is that work but got too big and I don’t have the time to single-handle this, even if someones decides to help me I still don’t have time to organize and keep everything running.
The S3 host will remain operative and so the ADUS backend. The API will be shutdown at the end of the month and with that the Voxel Launcher. The apt server will remain and might be used for other stuff, I don’t know. The Twitter handle will remain but be used for other stuff. The accounts page will be shutdown.
The Lux Vacuos page might get a rework and the name used for other stuff that isn’t game-dev related, it depends but meanwhile this blog remains. Also gonna use subdomains for other stuff.
I think that’s everything so, see you in a next project or whatever I do with this page.
So…. It’s been a while since the last post, I’ve been busy with University and other projects.
Let’s start with Light Engine
Early this year there was a point in Voxel development that it was begin bloated with unused features so I decided that the project need to be detached in two repos, one with the engine and game itself. Also Infinity was dead so I removed everything from that and started from voxel’s code, removing game-specific code from the engine.
With that done I started adding features, the entire physics system was replaced with JBullet, the networking was rewritten, major changes to the UI where done and the integration with Assimp. Currently is in a transition phase where the old code is begin replaced.
There are plans for writing tools like a map editor, entity editor and so on… but the time doesn’t allow me to start working on that.
So… Voxel development is halted for an undetermined time, I can only work in one project and porting Voxel to the new engine is very time consuming. I’ve done some work but the new physics system makes it a little complicated due to the infinite world.
Lux Vacuos itself
The only major change is the user account system that was replaced recently, apart from that everything is the same.
To end this, I really want to work on Light Engine and get Voxel to a decent state but the time is just too little to get everything done fast. Maybe mid-late 2018 I will start porting Voxel but meanwhile everything here will be quiet. That’s it for today post, have a nice day!
Today’s episode is a short one, there’s been major refactoring under-the-hood but is too boring for a video so I’m making this one. In this episode I add support for multiple languages and translations using .json files. Just that so, Enjoy! (there’s no music atm, maybe add in future episodes).
In this episode of “Voxel Gamedev”: I do the spotlight implementation and change how lights are loaded into the shaders. The spotlights are based in the Learn OpenGL, light casters article, although the lightning code is a minor modification of the PBR directional light.
Application Distribution & Updating System -ADUS- is a new system for application distribution and updating created from scratch for Voxel, and other applications. Is designed to be scalable, universal and easy to use, while maintaining simplicity and speed. In its core uses JSON files for versioning and configuration, and a repository in a multi-directory configuration containing all JAR files. It supports MD5 validation for jar files only, support for configuration will come soon. Other part is the application initialization: creates the command, classpath, custom parameters and then bootstraps the application using the main class specified in the configuration. Is not application-specific, meaning that can be used in any application.
The configuration consist of a main JSON containing all versions and a directory where the versions specific config is stored, the repository stores all jar files in a multi-directory layout. Using this system allows sharing files between versions.
The remote server is fully configurable, it stores the a full copy of versions and files while the client only downloads the files required, mirroring the file structure stored on the server. It can be used in a stand-alone mode or be complemented by a launcher.
I’ve been working in a new GUI for Voxel, this is still based on NanoVG for drawing but uses a new layout and display system. This is based on the idea of a Window Manager/Display Server, all the GUI is composed of “windows”, each window is composed of components (Buttons, Images, Text, etc), making the creation of menus more easy and fast. Of course custom windows can be made by extending the NanoWindow object.
Internally the Window Manager/Display Server uses a compositing renderer, this puts together all the windows and creates the final image that is displayed. Each window contains a buffer where everything is rendered, this is shared between the client-side area and the window frame. The logic (drag, maximize, close, etc) and decorations are done by the window itself, not the window manager.
The Window Manager takes the image of the buffer, applies custom shaders and then adds it to the final buffer. This is done in a back-to-front rendering. Because of the dynamic nature of NanoVG the entire rendering can be replaced or modified on-runtime.
That’s it, the anniversary of Lux Vacuos and the second year of Voxel development.
Has been 2 years since the start of this project, many things have happened in this short time, lets start by a video of the progress.
We started the year with the release of version 0.0.9, the new 0.0.10 version is in progress and is the most time-consuming update ever; it contains a lot of changes and rewrites to the code, new rendering system, new world system, nearly all the code is new. Also we have a new member, HACKhalo2, he has been doing all the rewrite and creating new stuff.
We launched a new update system for Voxel and support for .deb packages in Debian-based distros. With this the “snapshots” update channel become live.
The UI got a massive rewrite and a new layout system, designed to mimic a Window Manager.
The Deferred Renderer got an upgrade in the same way by using a PBR pipeline and diffuse irradiance, this feature made it’s way into Infinity.
More stuff is coming this year so keep close.
This is the first year of Lux Vacuos.
The idea of Lux Vacuos is to keep all the projects in a single place and to share the most resource between them. The big addition is the new account system, designed to share the same account in different places. Other minor changes where the updated logos for all projects.
We have more plans for this year and want to make them reality. This is all for today so have a nice day!.
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 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.