This is not a full update, just a recent peek at some improvements and performance. In my next full update I will release a video. If you are curious to know more about the planned development timeline, see the bottom of this post.

A constant question I get is something along the lines of "what is performance like?" The truthful answer was - I did not know! It looked like it was getting at least 60 FPS. Accurately measuring FPS can be tricky in OpenGL without profiling software, and I have not yet gotten to the point where I am using that (I don't want to get sucked into tweaking the heck out of things to profile this early on). If you think it is as simple as doing a timer between frames, that is not true. See here for further details on why getting the FPS can be tricky.

In order to perform these frame tests, I did it the old fashioned way - render a large amount of frames without any sort of timer constraints, and measure the amount of time it takes (in this case, I am measuring how long it takes to render 10,000 frames).

Some VERY important notes :D

These performance figures are still largely unoptimized. I suspect in the long run I can get at least 2x performance.

These performance figures are largely IRRELEVANT for isometric mode (which the game will still support) - in isometric mode, it need only render the scene once every so often as the camera moves larger distances, or when an environmental object is changed/destroyed. You could quite easily render an isometric scene at 1080p without much lag.

I have made a conscious decision to favor scene complexity over resolution (in fact, I think it is a bit ridiculous to play a game at 4k resolution these days when it only magnifies the inefficiencies in texture resolution and polygon count). I am intentionally trying to make the game look good at old resolutions similar to Mode 13h (or equivalent for widescreen). I loved the look of Doom, Hexen/Heretic, Ultima Underworld, and so forth.

Although these shots are untextured, the texturing is not a very expensive operation (I'll explain more about this trick soon!).

The date at which I targeted "going gold" is still 3 years away (although preliminary releases will be much sooner than that. During this time hardware will become faster and cheaper. The GTX 980 which I am rendering on now should cost $100-$200 if not less by then and about 50 percent of the users on Steam should have some as fast or faster than that, extrapolating from current hardware surveys. I am targeting to get it running well on a GTX 960 or equivalent, which should already be feasible but I need to test.

The interesting thing is that the object count makes little difference. In some cases, rendering 10,000 objects is faster than rendering 1,000 objects (due to occlusion). There is no limit on how many objects you can render - you can render a million objects with little change in performance. By the way these objects (which are an extension of superellipsoids) can render any classic piece of geometry like cones, spheres, diamonds, triangular prisms or ramps, and more - all using one instruction set. Below this I have included a couple further updates from the Voxel Quest twitter account regarding improvements and further tests with this rendering.

(Edit) Also note that the point here is not so much to compete pixel for pixel with a polygon engine. I can do things that could simply never be done with polygon engines, and that realistically requires a sacrifice to both resolution and performance. These are SOLID objects that can be updated with completely different geometry, volumetric textures, and whatever in realtime. While rendering one object might be slower in my engine, you must account for the fact that I can render millions of objects faster than a polygon engine could. In other words, my engine is resolution-dependent, not polygon-dependent.

The new rendering methods now support any amount of overlapping geometry (previously, each piece of geometry was constrained to one instance within its own cell. There is still more work to do before I do a full writeup, as the process is still changing slightly and there are more steps to finish. I am also doing a huge amount of work just to manage dynamically placing objects in the scene, saving your creations, and a lot of stuff along those lines, which I will also talk about in the next update.

I'm not going to type a ton about the development status of the game - I've already done that in the forums if you are curious (check recent threads). But let me just provide a brief summary of recent issues:

I am finishing the tech side of things this month, and all focus will be on gameplay once that is done (FOR REAL).

I am shipping a minimally viable prototype game ASAP that will be a slight deviation from the long term goals of VQ. I am still planning to achieve my long term goals, but that will be down the road. The first goal is to get something fun into the hands of backers and ensure that I don't get stuck on hard problems in the short run.

I am in the middle of raising funds to complete the game. I am currently considering money from acquaintances I know and angels. I have enough funds in place to carry me for a good while longer, it is mostly a matter of choosing who to take money from at this point (and fingers crossed that at least one or more of these deals actually goes through, as getting the signed check is not always the same as getting the "ok"). My primary goal is to not compromise my vision or freedom in this process, which seems viable based on who has offered so far.

There have been many reasons for the delays thus far, largely involving tech revisions, and being adamant about shipping a "fun" game. I have intentionally not given a hard release date because I realistically don't know when that will be, but I am striving to both get a tech demo out in the short term, get the source ready to distribute, and to get a minimally viable and fun game out.