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

Just stumbled upon a good stress-test map: Ex Inferis megawad, map07. With not so vast open space and just about 200 monsters it drops the FPS to single digit values.

OK, it could by just a shitty level design, but previous levels were pretty neat so far.

thank you! the HUD is hardcoded for now, and you can only scale it by 2,3,etc. yet i'm working on making status info independent of HUD messages, and to make it fully user-configurable. the idea is that you will have a set of "widgets" you could use to build your status info with (using a kind of drag-n-drop), and it will be possible to scale them freely too. i'm still designing that system (to make it easy to use and flexible), but it was in my TODO list from the very beginning, and it will be there sooner or later. ;-)

for those watching repo commits: everything is ok, i'm alive! ;-) got distacted again by some ZX Spectrum projects, but i will return to k8vavoom soon.

Hello. I already asked about ipk3 (https://www.doomworld.com/forum/post/2447695), unfortunately the ipk3 known to me contains a z-script and does not run in k8vavoom. Does anyone know ipk3 that work with k8vavoom?

I'm not a big fan of the ZX Spectrum itself, but new tooling for old consoles (or well, computers) is always awesome. You really don't have a limit to your skills, do you?

Anyway, because I'm usually here to report bugs, here's a couple "bugs" to fulfill my per-post quota, lol.

ColorSetters in K8Vavoom are "static", that is, they only work when placed on the map, and only do anything at map start, not when spawned mid-game. However, in ZDoom, you can spawn them mid-game and they'll color the sector as expected (and not very important, but for some reason the mobj still sticks around after that). This is highly useful, because it's the only way to patch sector colors into maps across Zandronum, K8Vavoom and GZDoom (without actually modifying any files of course).

Optimally, please make the setter wait at least one tic before coloring, otherwise the trick still wouldn't work (and I think that's accurate to ZDoom, even if unintentional there is a very short delay between the colorsetter spawning, and it actually coloring anything). I cobbled up a crappy fix for it with VavoomC so at least I personally don't have too much issue if it isn't fixed or if that isn't taken into account, but still thought you should be aware.

Also related to sector colors, they look much duller than in ZDoom (in this case, Zandronum, but the newer renderer looks about the same). I can't quite put my finger on why that is, but it seems like they're too bright in comparison. Here's a pair of screenshots:


This might just be my crappy drivers, but I'm not entirely sure as I don't have much else to test on.

EDIT: Almost forgot. I guess the answer is no since MODELDEF is converted to K8V's model XML defs, but does the latter have any way to work around the bugs with pitch and such in MODELDEF? I'd love to try and get my game to work correctly in K8Vavoom, but that makes it a bit hard since everything is a model in it.

Hi, this is ENEMY!!! from the Doomworld forums, I wanted to mention that the glitch with transparency in scrolling cloud textures is still present in the latest version. I remember you patched out the glitch in an earlier version of k8Vavoom but it crept back in. It seems that the problem is that every transparency value above a certain percent is being rendered as 100%.

Sure, here. Every 2 seconds it'll pick a random color for the sector in front of you.
Attachment Deleted
I made a mistake when trying the first time. The ColorSetters were actually not spawning at all, and when I tried to spawn one with the summon CCMD, it said that the actor didn't have a spawn state, so I got confused. When I made the VavoomC hack I just made BeginPlay a separate function and called that on a spawn state after 1 tic, so thought that had to do with the initial issue with them not spawning. I should really learn to make 100% sure before reporting lol

Trying again, it does actually spawn, but it doesn't wait a tic before coloring the sector, so in this sample the sector always gets colored black either way. Technically not a bug but it's still not accurate to ZDoom that way!



That's very useful, I'll keep it in mind. About the problems, I mean like that I reported last time where INHERITACTORPITCH was inverted (to the point where models were upside down, even with straight forward pitch!). But now I realize why that is.

Supposedly the actual ZDoom wiki even states that INHERITACTORPITCH is inverted but... that's not true? The only time it was ever true, was all the way back in GZDoom 2.4. And ONLY in 2.4, not any previous or later version AFAICT. Certainly no longer the case in any of the 3.x series builds onwards or any of the 1.x ones I tested with. In 4.x, INHERITACTORPITCH and USEACTORPITCH are 1:1 identical, even. Was this intentional on K8Vavoom's end, then, based off that? USEACTORPITCH does work just like in GZDoom.

One last thing. I know K8Vavoom doesn't support the same user shader defs in GLDEFS Zandro and GZDoom do, but is there any alternative way to add some?

EDIT: Re-uploaded the WAD.

oh, i just realised that i didn't told ya when i'm planning to return to k8vavoom! i think it will be autumn, because my Speccy projects turned out to be bigger than i expected. sorry for this delay, but sometimes i want to so Something Completely Different. ;-)

(at least i hope so. the situation in Ukraine is far from good, so it's all hopes and positive thinking on my side. ;-)

Oh and one more thing

K8Vavoom is pretty much (along with my own Sprinkled) my de-facto source port that I use for youtube videos.  I'm wondering about scaling options, if it is possible to implement a scaling system that would allow for 320x200 / 320x240 rendering but upscaled.  Something that Chocolate Doom does, because currently, the scaling system pretty much prevents any resolution being used below 720p (on a 1080p monitor), it just descends into a mess of pixels that looks 100x worse than even vanilla.

Alternatively an option for the scaler that would set the renderer to a specific resolution but still display the image as fully upscaled.  As currently, if I'm on 1080p and use anything above 1, the scaler is way too strong and pushes it to something that looks like 100x80

I been gone a for a while (real life stuff) Not trying to rush you ketmar, but any word on a new K8Vavoom build?

sorry for late answers, people: goggle finally killed POP3, so i stopped getting any e-mail notifications. and i cannot use most sites with my personal e-mail server, because they either believe that my address is invalid (no sane person can have their own e-mail server, right?), or want a confirmation reply (which doesn't work, because Big Providers rejecting mails from my personal server as "spam", often on SMTP stage).

i mean, it is harder for me to notice your posts now, so don't worry if i'm not replying for some time.

now for the real replies.



there was a request for presets, it is still in ticket database, and i will implement it sooner or later. ;-) as for better options menus… yeah, i know that option menus sux, because i sux at building UIs. suggestions are welcome! i may not be able to implement them, but they are still valuable, because i may implement something similar instead.

presets should solve both problems, but until then, alas. and i made tracers on by default exactly because people usually never going to explore the options, and nobody will know that the feature is there at all. ;-) again, this will be solved by presets (i will prolly show some possible presets on the first run), but somebody have to implement those presets first… ;-)


yay! thank you!


in "screen resolution" there is "screen scale" option. what it internally does is divides your current resolution by the scaling factor, rendering the screen with that new resolution, and upscales it back. so if you have 1280x1024 resoultion set, for example, and scale factor 3, the internal rendering will be done in ~420x340. currently, this is the only way to control internal rendering resolution (it was the easiest way to implement it for the current rendering subsytem). it's not ideal, but at least something.

and if you mean that you tried exactly that, and it doesn't work as you want… i can't see what could be done here. lo-res rendering will inevitably become a pixel mess. or i didn't undertood you at all?

i mean, 1080/3 is 360, quite close to the vanilla.



thank you! yes, maps with a lot of details (read: visible linedefs) are much slower than in GZDoom. alas, this cannot be solved with the current renderer, the bottlenecks are both CPU and GPU. the problem is that rewriting the code to better utilise modern GPUs will kill the performance of lightmapped mode.

currently, lightmapped mode is much faster than shadows, due to less render passes. and the only way to maintain new GPU-optimised renderer is to ditch everything, and unify lightmaps/shadows into one common rendering path (otherwise i simply won't be able to maintain it).

sadly, such unification will mean the same multipass rendering for both lightmaps, and shadows, and old GPUs will have to render the scene 5+ times instead of 2+ in lightmapped mode. a major slowdown. i'm not yet sure that The Time Has Come to make such bold move. ;-) i wanted to write "unified renderer" for a long time (less maintenance burden), but didn't done it due to this reasons.



yay! hi there! ;-) i think that the work on the next build will start close to the end of this summer, so new build will prolly not arrive before the autumn.