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

Nice to see it here too. I’ll still be doing those MinGW builds too!

oops. i just realized that k8vavoom is not the only doom port out there. ;-) i mean, here, original Aliens mod. don't run it with the current k8v public build, tho — there are several engine bugs i fixed to make it work properly.

as i don't want to work on something really complex yet (like renderer rewrite ;-), i added some useful APIs to allow creating mods like Corruption Cards. basically, almost everything you need for it was already there, i mostly added a way to allow native VavoomC in-game GUIs easily speak to playsim (so you won't need to use ACS to create CC-like menus).

no, don't expect me to port CC, it is too big, and i am too lazy. but i may release a "CC-Demo" later, just to show you all that k8vavoom is at least as powerful as GZDoom.

of course, don't expect that demo to survive for long (because VavoomC API is not designed as a stable one). i just thought that it would be fun to show some REAL POWER of k8vavoom technology.

i'm still against using VavoomC for modding (at least if you aren't ready to learn everything by yourself, and don't want to support your mod until the heat death of the Universe), but sometimes i want to show people that k8vavoom is hiding treasures inside, and it can do almost anything GZDoom can do, and even more. ;-)


p.s.: i also fixed several small bugs while doing it. they are mostly related to VavoomC-based modding, so they won't really affect you, but the only good bug is a dead bug! ;-)

Sorry, but Windows 10 doesn't like to download files. Need to make a few mouse movements for permissions. I beg you, please make an official channel.
Personally, I prefer this one, it does not require special permissions, for example, on the size of the video, like YouTube: open.tube/accounts/camper/video-channels

and another small video. just for fun, i implemented 3 cards (mostly to test UI). as you can see, i selected two (this is, again, simply for testing), and monsters immediately started to attack me, and they exploding on death.

of course, scanning all objects on each tic to check if some monster died is absolutely inefficient. adding some inventory item to all monsters to drop on death could work, but that's not fun. so "explosion" card intercepts `EntityEx.Died()` method instead (this is internal engine method called when something died). besides being faster, it is also possible to know who killed the victim, and with which projectile (if there is any).

i wasn't joking when i said that k8vavoom is written in VavoomC! it really is, and VavoomC compiler allows you to use some tricks to extend already existing internal engine classes (`EntityEx`, in this case). and such mods would properly stack too (with proper coding, of course).

of course, VavoomC mods are inherently unsafe: techincally they become the engine code. so malicious VavoomC mod can easily crash the engine (but it cannot access arbitrary files or network directly). as VavoomC has pointers, with some trickery it is prolly possible to write an exploit with arbitrary code execution, but i believe that it will be harder than reach the Moon by jumping. ;-)


p.s.: just to make things slightly more clear: Vavoom was able to do this more than a decade ago. i only added a way to load VC code from user pk3s (with the same loader that loads the main engine code), and some callbacks. it was THAT powerful when ZDoom couldn't even dream about such things.

It has nothing to do with Win10. Looks like the forum's engine wraps the original url with some spam-oriented site that is blacklisted either in a browser on in an ad-blocker or in an antivirus. But if you click the "Quote" button, you'll get the original link without this nasty addition. 

also. partial support for SBARINFO.

standard Doom statusbar:


Aliens mod HUD:


yeah, "statusbar mode" is that big, because they are designed for 320x200. fullscreen SBARINFO HUDs usually can be scaled down (the option is there too).

it will never be in the engine core, SBARINFO is cancer and idiocity. this is a standalone VC mod. i'll prolly make it public after releasing the next build, but don't expect it to support everything, or to be maintained at all. i'm just showing what is possible with VC code, so people won't use it even more. ;-)

you know what? yes, this is exactly the plan for the long-term HUD rewrite! ;-)

currently, many parts of HUD code are duplicated across the games (i.e. Doom/Heretic/Hexen/Strife are using their own copied of HUD code), and non-Doom HUDs are not properly updated. The Plan is to unify that into reusable HUD components, and yeah, one of the features planned is interactive HUD creation by placing and moving widgets. with the ability to save "presets", and maybe even associate them with individual PWADs.

but don't expect it to appear in next month or something, of course. ;-) this is just one of the things i have in my REALLY HUGE TODO list, and i have to manage priorities. but i'll implement it sooner or later.

yay, hi, tdrr! great to see you here! seems that it's time to ask 40oz for some money for bringing new creative users at DB! ;-)


thank you a lot!


the language is more… consistent too, i think. at least i love it more. ;-) just to be fair here: most of the work you see was done by Janis, including basically rewriting the whole engine in VavoomC (several times). i extended the language with various useful features, and did some cleanups, but most of the foundation is still from Vavoom. and i must confess that Vavoom codebase was one of the major reasons why i forked it: it was a pleasure to work with.


i am usually trying to not break things without a good reason, and provide a compatibility workaround if it is possible. but of course, it is hard to promise anything.

yet at this stage i believe that you can expect most of the playsim to stay more-or-less stable. basically, there is a usual conflict between speed and extensibility. i would love to make everything extensible, but each such change makes the engine slightly slower. it may be a little here, and a little there, but those slowdowns sum up…

for example, you cannot override DECORATE actions yet (`A_xxx()`), they are marked as `final`. this is one of the limitations i want to remove in the future. and i want to add more hooks, so you don't have to override internal engine methods to do various things (like overriding `EntityEx.Died()` to take some action on mobj death) — this will allow me to change engine internals while keeping VC mod API stable. but each such callback is yet another slowdown.

i am (slowly) working on JIT compiler, and various other compiler improvements to make this all possible, tho. so yeah, there will definitely be some stable API you can rely on in the future. we just not there yet, and i have a lot on my plate already. but being "VavoomC mods friendly" is one of the project goals.

i also started adding comments for VC modders right into the code, so the codebase will eventually become more friendly.

i must warn you, tho, that UI part of the code is VERY unstable as for now. the whole UI system is pending a major rewrite: Janis left it in a very unfinished state (tbh, he barely started rewritting it properly), and i'm planning to use this oportunity to redesign the whole thing.



yeah. and i am always ready to help too. most of the time when something was changed, you only need to fix one or two minor things here and there to make it work again, and i'm always glad to help with that.


yay! it's great to hear this! tbh, i think that stenciled lighting is not something one should use anyway: it is MUCH slower than shadowmaps on any complex geometry, and it cannot cast shadows from textures. i am mostly leaving it there because it doesn't cost me much (most of the code for stenciled lighting and shadowmaps is shared anyway). but i must confess that i stopped playing with stenciled lighting after implementing shadowmaps, so that code is slowly rotting.

yeah, i mostly added various small things to make my own life easier. like `auto` for variable declarations, UFCS, more sanity checks, some compiler warnings, `foreach` for arrays, etc. one of the major additions is `dictionary` data type (not limited to several compiler-supported variants, like in ZScript), and struct methods. i also implemented some compiler optimisations, and other such things. but the core language is mostly unchanged. well, except that overriding methods now requires explicit `override` keyword, and instantiation is using `!` now (i.e. instead of `class<Actor>`, you should write `class!Actor`). i also removed external declarations for DECORATE methods, and added syntax to mark methods (and constants) as "accessible from decorate". but mostly many small-scale changes here and there that you will prolly not notice… until they are missing. ;-)

ah, i also added stack traces on VC code crash. i can't even imagine how Janis managed to debug Vavoom without that feature.


the engine is actually cheating like hell. ;-) for example, it completely skips any physics playsim code (which is written in VavoomC) if it can detect that some object is unaffected by physics. i.e. there is no need to call physics code for most dormant mosters, for many pickups, decorations, and such. this way you can still play "Memorial" with it's 4K monsters at acceptable framerate, for example (because most of those monsters are dormant).

Gore mod is quite slow, tho, but now you can dynamically turn it on/off, which helps a lot on some slaughtermaps. on my old core2duo the engine is able to process up to 1k active monsters, and still maintain 30-40 FPS.


my rough estimation is at least x3-x8 speedup. tbh, the biggest problem is that i have to support several CPU architectures, and none of the existing JIT engines can do exactly what i need. i'd like to avoid writing my own SSA compiler from scratch, so i'm still trying various libs. but it looks like in the end of the day, i'll have to write my own. sigh.


i don't want people to use VavoomC (at least not now, for obvious reasons), but of course, if somebody is brave enough, than it wouldn't be fair to left them without help! ;-)


sure, feel free to drop the code at me.


yeah, you're basically working with the "raw engine", without any intermediate helpers and safety nets here. and engine internals are not as straightforward as it may seem. ;-) due to idTech1 legacy, some things are done in very convoluted ways, and some things should be done exactly one way and in the right time, and… oh, the joys of idTech1! ;-)

i'm planning to start documenting at least most obscure parts once i'll get closer to something stable.


yeah, i love their look too, but alas, the algorithm itself doesn't allow to add any fancy features, or make them faster. the main problem is that stencil shadows overdraws like hell. i added various tricks to limit overdraws, but the core algo depends on overdrawing. and it absolutely kills any GPU, eating all memory bandwidth, and still wanting for more.

it is possible to add a geometry optimisation pass to make stencil shadows slightly more faster, but they won't realisticaly reach the speed of shadowmaps anyway. and i'm not done with shadowmaps yet, i have some ideas how to optimise them even more. so i prolly won't remove stencil shadows, but i also won't invest much efforts to improve them too. it simply doesn't worth it (cosidering my limited resources).


oh, yeah, thank you! i simply forgot to do that. so i added a ticket for that, so it will annoy me and i'll have to redesign the opening post. ;-)