k8vavoom: no good thing ever dies! (2023, Dec 22 build)

I know this might be an absurd suggestion, but have you considered either updating your drivers or trying a live Linux distro to test out K8Vavoom? Puppy Linux is small and getting the Windows build of K8Vavoom running is really easy, and you can do it all from an USB drive without having to install anything. I can guide you through the process if you want to check that out.

Granted, it'd just be for playing, unless you either want to try running Doom Builder through Wine (not recommended at all lol) or learn a native Linux map editor like SLADE or Eureka (which also isn't great since this all takes a lot of getting used to), but at least trying out K8Vavoom is worth it IMO.

Or just buying a GPU. I have an Nvidia GT 730 and Ketmar himself has a GT 720, either does the job really well for K8Vavoom (and all Dooming needs really), they don't require a beefy power supply, go for very cheap and are super easy to install.

dev diary #iforgot. ;-)

one thing i really want to implement for a long time is a proper 3d clipper. currently, the engine is using 2d clipping, and it's a problem. this clipper has no idea of height, so, for example, out-of-screen window in a wall will not clip rendering. i added several hacks for such cases, but 2d nature of the clipper still manifests itself. also, 2d clipper doesn't work good enough with freelook.

another way to implement clipping is to use fullscreen span buffer (like Quake and Unreal). with BSP we have strict front-to-back rendering order, and can perform clipping with pixel precision, regardless of camera orientation. such clipper is slower than 2d, but can give a speedup due to processing less geometry.

second thing i need to implement is sprite clipping. currently, the engine renders all sprites from the visible sector. it doesn't matter much for "normal" maps, but complex maps with a lot of monsters is a different deal. i have test maps where single-digit FPS could be turned to 60 by turning off (voxel) mobj rendering. the problem is that the player sees a small part of a huge sector with many monsters inside. no monsters could be seen, but the engine still renders them all. and rendering sprites eats both CPU and GPU.

all those invisible sprites should be lit by dynamic lights too. of course, the engine tries to clip invisible lights (and this clipper is way more aggressive than sprite clipper), but such clipping is an approximation, and some useless work is still done.

also, there could be some sense in introducing dynamic sprite atlases. most of the time the player sees the same sprites (so-called temporal coherency), so instead of using one texture per sprite frame (switching textures is slow), we can gather them in one big "atlas". currently, the engine tries to sort sprites by their textures to minimise texture switches, but tbh, this doesn't really help.

and of course, i need to cache map geometry in GPU RAM instead of sending it again and again each frame. this can drastically decrease the amount of data the engine sends to GPU (rough estimation: 3-10 times). it really matters for complex maps (Frozen Time bridge scene, for example).

long-term plans: with proper 3d clipping, i will (again) try to implement floodfill rendering, and dynamic sector tesselation. this may (or may not ;-) give us the ability to freely move sectors around, a-la Build. this needs properly built maps, tho (with properly closed sectors, and without missing textures), so old-style BSP renderer will not go away.

there are several other problems to solve with "no BSP": BSP tree is used for may things besides rendering, including hitscan tracing (sometimes) and light culling. so i will need to develop several new algorithms, not only renderer. that's why it is a "long-term" plan.

currently, my plan is to write a specialised memory manager for this. upload the initial geometry (with some vertex attributes) completely to GPU, and use triangle fans/strips (as does model code now). this way, we can render the whole subsector flat with only one number, for example. we can also join adjacent subsectors into "megastrips", and render them as a whole (because it should be cheaper to allow GPU to do some more work instead of trying to cull everything with CPU).

custom memory manager is required mostly due to t-junction fixer: number of vertices per surface is not constant, so i need to free/move vertex blocks on updates (and eventually just wipe everything and start from the scratch).

k8v does partial per-frame caching now (because rendering one frame requires several passes over the geometry), it makes things slightly faster (1-3 FPS more).

i'm also trying to invent some way to cache shadowmaps. for most static lights it should be possible to cache traced shadows, i believe. shadowmaps are expensive, because i need to snap trace origin to texel center, to minimise acne/piterpaning.

sadly, i cannot use texture selection in shaders without bumping minimum OpenGL requirements to 4.6.

maybe i'll write a standalone PoC for geometry caching. if i go that way, i'll share the code with you.

p.s.: i don't know much about gfx too, so i'm "learning by doing". ;-)

I think is because every cube is treated as a individual model (I'm probably talking pure nosense, but I recall thats how GZDoom does iirc).

Idk, I'm not a programmer just probably saying a lot of bullshit

Herr Dethnout, oh, and i forgot to say that you're right about the idea of voxel → model conversion, of course! we invented several methods to optimise the result, but the basic idea is exactly what you wrote. now you're officially The Programmer! ;-)

they look exactly as they were before. ;-) i've never seen any probems with model shadows.

It looks like this for me:

streamable.com/xyde9w



But in general, my system (windows10, AMD Ryzen 5 3500U with Radeon Vega) has some peculiarities, I already talked about the lack of water texture on q2doom.pk3, but others, as far as I know, everything is fine with water: ibb.co/FhtJ4Z2

I remember hearing all the time that AMD driver updates kept breaking GZDoom. Those were the days :)

If you're using nVidia with Linux, you'll want the actual nVidia drivers and not nouveau. When it comes to open-source drivers for Linux, AMD blows them out of the water.

and btw, i really-really-really want to replace VavoomC with Oberon. the only thing that stops me is 4MB of VavoomC code i will need to rewrite. ;-)

(this is actually greater than real C++ code amount!)

tbh, i never had any problems with proprietary nvidia driver installer. just download and run, and that's all.

but of course, i stopped upgrading nvidia driver years ago, because they stopped uploading 32-bit builds. i hate that idiotic 64 bit craze.