Venture The Void - Recent Shader Work

What I did this week


Venture the Void is a 15-year old project for me-- as in, I released it 15 years ago, or nearly.

I spent a great deal of time on it but it suffered bitrot, and I also had emotional issues with it, so I tried to forget about it.

As time passed I realized I was really being unduly hard and the fact I had created something like this, it deserved to be kept in some sort of workable form. I started to clean up the code just to the point of getting it to run on Windows, but ultimately lost my enthusiasm for it-- I think I was still working out where I related to it emotionally. Long projects are really something!

Finally last year I got it out onto, and am developing it as a kind of mutation experiment, gradually transforming the game into something else. I guess the game will become its own sequel? Or maybe, shed of external expectations that I think kind of grounded it artistically in the first place.

Anyhow-- the process to do this is very interesting. How do you take a game that is lacklustre in many regards but already complete and start to remake it wholly? There's a lot of parts to this kind of thing!

The approach I'm taking is to tackle the visuals first.

The first part of that, is reworking the rendering to use (a bit) more modern OpenGL. Venture the Void is written against GL 1.2, which is an incredibly old (but, actually, conceptually very cool) 3D engine, not really compatible with modern shaders.

I really need to have access to shaders to do anything with this.

I would like to jump to GL 3.x1 but this is very, very hard, because the lighting and (especially) transformation pipelines present in GL 1.2 do not exist in 3.x, so this means very major and global changes to your rendering pipeline.

OpenGL 1.2, by the way, has the funny property that it's actually incredibly easy to draw a single triangle on the screen, which is the entire opposite of what it's known for now. More people should think about GL 1.2 conceptually and recognize that it was very great! It got shoved off a cliff because humans chase shiny and fancy things, and GL 1.2 sort of is limited performance or rendering-flexibility-wise but... yeah! GL 1.2 forever! The Real Texas is actually all GL 1.2.

So what I'm doing instead, is revamping it to GL 2.x. This version itself is ancient but it will let me get to shaders while keeping the fixed transformation and lighting pipeline in place. GL 2.x is sort of transitional-- they added shaders and a lot of good modern stuff not present in 1.2, but they still had a fixed pipeline-- conceptually. But it then became apparent that the fixed pipeline didn't really make sense with general purpose shaders, since they might or might not use the parts of the fixed pipeline they way they are defined, so then we get GL 3.x, where it's totally abstracted. GL 3.x is more stripped-down and in some sense simpler, but you have to do more work yourself.

So the point is, jumping from GL 1.2 => 2.x is doable, and then from there jumping from 2.x => 3.x is doable, too, if I even want to. 2.x might be enough for me!

1 you can think of GL 3.x as being the version before Vulkan, basically... everything past GL 3.x was more or less incremental... fight me!

First shader - Geomap

Diving into the huge mess of the code, I realized that actually almost everything in Venture the Void is drawn by one or two classes. One is the geomap renderer, this renders planets and other "big spheres" like oceans on planets, or the surface or stars.

The other is the "kmesh" renderer. "k" as opposed to "p". Venture the Void development had a ton of work done for progressive meshes and other level of detail control. Ultimately I think that either my ability or the hardware I was using was not quite there, so I ended up using fixed detail meshes (the terrain, aka, "geomaps", still have progressive detail, and it works very nice, and actually I think it's a novel algorithm-- I should publish it!)

So I had a "pmesh" class, but it didn't work great, so I wrote a "kmesh" class (k for "konstant detail", you see.)

Anyhow-- the geomap cleanup to use shaders (and vertex buffer objects) is done. I can't quite believe it-- I really was expecting this to be harder than it was. Fortunately, the implementation of this part of the code is actually quite clean! I'm amazed! It was fairly straightforward to make it work.

One problem is the lighting and blending. Because OpenGL 1.2 is fixed-pipeline, there is sort of a way you can separate out "material" properties, including texturing, from "geometry" properties, such as meshes. Venture the Void does this, but with shaders you actually kind of want to marry the two more closely. You can precalculate a bunch of useful stuff and shove it over to the shader as desired.

So what I know I want to do is eventually change the lighting completely, so I'm not worrying about the lighting or blending. Basically, I'm only trying to capture the behaviour of texturing and geometry, not lighting. This is stage 1. I'm not trying to re-create the original look in shaders, I eventually want a new look-- so the dividing line for me that I'm cutting things off at is lighting-slash-blending.

I don't want to prevent myself making more releases though, so for now I have the new shader-enabled code flagged to only build on the development version.

Second shader - Kmesh

This will be next. It's considerably less complex than the Geomap code, so I'm hoping it won't be too bad. The interactions with materials are greater though so we'll see! (Geomaps are always rendering terrain, water, or star-plasma-- kmeshes might be rendering buildings, explosions, etc.)

Next up - Generation

At this point, I will actually be in a position to start revamping visuals. This is actually much quicker than I expected!

The way the game works, the existing "universe generation" program (called "Umake") actually spits out very specific details on how to render things-- too specific. The universe generation really should output parameters for the universe, and the game engine should then synthesize them into planets, ships, etc.

This will be an interesting problem, and I'm not yet sure how I'll tackle it.

My best strategy right now is that umake will still spit out the "v1" files, but will also spit out a definition file that can then be used by the engine to generate the "v2" visuals. This will let me start to actually change the look of the game.

What to Expect and When

For now, I'll keep pushing updates with the current visuals and add new world files. (Remember the game is already complete and on for five spacebucks and it's worth that for the music alone...)

At some point though, I'll drop a new version and the visuals will change-- dramatically. I'll talk more about what my intent is at that point. The change will probably be a bit disappointing to some people who enjoy the sort-of N64 or PSX vibe the game has, but this is what I want to do with it.

I'll keep old versions downloadable though, and try to push out a bunch of different world files before then, so that people fond of the "old" retro look of things will have lots to munch on. I'm not trying to retcon my past stuff, I'm using it as base material to experiment with.

Anyways this is all very enjoyable and working a bit better than anticipated. I had originally though a visual revamp was a very long ways off, but it might not be that distant after all.

August 8, 2020

◀ Back