The spring months have been a little crazy with various Real Life time sinks preventing me from delving too deep into fun coding. Consequently, there has been little to no progress with the tasks on the roadmap, such as the multiplayer improvements for version 2.1. Given that several months have passed, it will be challenging to find motivation to restart this work. I am tempted to make some changes to the roadmap to get things rolling along again.
I have managed to steal away some time to explore an exciting new direction for the renderer, though. The basic gist of this effort is to completely revise how the game world is drawn, bringing it up to par with the recently redone 3D model renderer.
Doomsday’s “first-gen” rendering code is well past its best-by date. It was originally written for OpenGL version 1 way back in the year 2000. Since then some superficial improvements have been made, but it fundamentally relies too much on the CPU for processing the map geometry. Nowadays the GPU should be handling all the heavy lifting.
The approach I have chosen is a clean room implementation of an independently designed new renderer. This affords me the opportunity to reconsider all the assumptions about how map data is structured, and revise it to support things like slopes while keeping it fully compatible with Doom-style 2.5D maps.
While one important aspect of the new renderer is to allow efficient low-end rendering on Android/iOS (where the CPU should do as little as possible), it also needs to scale to high-end GPUs. For this kind of scaling to work, it means that both the materials and the surface geometry need to be radically enhanced for the high end. So far I’ve been exploring the different possibilities to bring additional detail to the world (for instance displacement mapping, shown together with screen-space ambient occlusion in the image at the head of this post). Overall it seems pretty clear that all of these enhancements can’t be done automatically: manually created PBR materials and hand-crafted surface details will need to factor in to the system.
Once a prototype of the new renderer is up and running and the appropriate rendering techniques have been chosen, it can be introduced as an alternative to the old renderer. It will likely be necessary to keep the Classic renderer around for some time, until the new one is sufficiently polished.
I leave you with this early screenshot where I was testing simple parallax mapping. Other noteworthy features shown here are HDR lighting and shadow mapping using a cubemap.
