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.
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.
The project started as a fork of Voxel with some modifications so can be used as a Game Engine but was abandoned after some time due to Voxel became the main project, now reborn as a Physically Based Rendering Engine. The difference is that now only works as a rendering engine leaving all the game logic to the programmer (Physics, Stages, Map, etc). This allows a modular, lighter and portable engine that isn’t limited to specific needs of a game. The base code for this engine will come from Voxel’s rendering system, this renderer supports a lot of features but is tied to the game logic making it hard to use in other projects.
The rewrite is progressing very well, major parts of the World system are nearly completed and the rendering is starting to be re factored, the Windowing code has been re factored and now supports new features as multiple windows and better input. The rendering system will be detached in modules that implements a generic API, this allows to the engine to switch between OpenGL or Vulkan. This system allows to use multiple rendering APIs without changing code that no relies on the generic API.
Screen Space Lights
The engine now supports Screen Space Lights, this technique of rendering lights uses the data stored in the GBuffers and renders the lights in Screen Space, the advantages of using this are:
Better performance: instead of rendering in the pixels of the model they are renderer in a flat quad using the data available.
Nearly infinite lights: right now supports 256 independent point lights to be rendered in a single call.
The WordPress Theme code used in this page is now available using the GNU GPL 3.0 Licence. All the code and assets are available here: WP-Theme. Please be aware that this code is used specifically with this page, we don’t recommend creating a site with the theme because has some stuff hardcoded, instead recommend to only contribute with code.
The Voxelcode is being rewrittenbyHACKhalo2, from 70% to 80% is new code. Most features are retained but some had to be modifiedto accommodate the new code. Here is a list of what features were changed or replaced
ECS Components has been reworked.
The reason for this is to convert Universal in the core and on top write the client and server, this serves to keep most of the shared code in one place, speeding up the development process. The actual state of the code don’t allow to play, because of that there will be no updates until reaches a playable state.
If you what to check the process or contribute please go to Github.