k8vavoom: no good thing ever dies!

@Gunrock yay, looks absolutely great! and thank you!

i am also planning to bring bloom filter to k8vavoom, to make it look even better. and i'm looking into implementing voxel models too. this is among other, bigger plans. our great jorney is barely started, an oh, what wonders waits for us ahead?! ;-)

 hey @ketmar have you seen this yet?

16 hours ago, Voltcom said:

could you make it possible to load pk3 files?

but k8vavoom supports pk3! ;-) it can both load pk3 directly, or load pk3 from zip archive w/o unpacking (idarchive loves to put pk3 into zips). it also supports lzma compression method for pk3. yet k8vavoom doesn't support pk7/7z: 7z sdk code is... not the best one. base k8vavoom data stored in pk3 too.

note that some people are using ".pk3" extension for 7z archives. k8vavoom will become angry about that, and will swear a little. ;-)

but if you mean some kind of launcher (like, window to select something at the start) -- that is not planned. even such simple UI is hard to build for several platforms, so i'd better leave that to dedicated launchers, like zdl.

16 hours ago, Voltcom said:

Aside from that it's bloody brilliant!

thank you! we also have alot to offer for modders (at least not less than GZDoom with zscript, maybe even slightly more), but i'm not yet sure that i want to document it.

also, for now k8vavoom doesn't support multiplayer. it is there, but i broke it. ;-) but MP will be restored soon (i hope).

12 hours ago, therektafire said:

hey @ketmar have you seen this yet?

wow, great news! software panents must die. k8vavoom already using "carmack's reverse", of course, but IANAL, and i just hoped that nobody will notice. ;-)

i am still planning to write some combined algo, though (maybe ZP+), because zpass can be somewhat faster for some cases.

6 hours ago, Voltcom said:

I'm dumb that's all

don't worry, it's ok. exactly the words i'm screaming at least several times a day, especially when reading the code i wrote yesterday. ;-)

also, your post is very valuable, because such posts gives me yet another opportunity to write about k8vavoom features! ;-)

my so-called vacation goes completely off-rails, so expect a new public build soon. ;-)

this time i made some improvements to lightmapping code. the most important thing is that the engine should not crash with "surface cache overflow" anymore, ever (previously, this may happen on maps with huge open spaces, and alot of lighting).

also, i am working on on-disk lightmap cache, so static map lighting will be calculated only once. currently, the engine does full static light recalc each time the map is loaded (this includes loading a saved game), which is obviously not so good for maps with alot of lights. i hope to finish this for the next public build (there are some problems to solve yet, but nothing really hard, i hope).

27 minutes ago, Voltcom said:

Sorry to hear about the vacation

thank you. tbh, my "vacation" was just a try to take some rest, and stop coding k8vavoom for a little. and of course, i failed it -- the more i am trying to forget about engine coding, the more ideas i want to try RIGHT NOW, OH, IT ABSOLUTELY CANNOT WAIT! ;-)

the first draft of lightmap caching seems to work now. it is not as good as i want it to be, but at least it works sometimes, which is better than what we had before anyway. at least quickloads shoud be quick most of the time even on slow CPUs (i hope).

let there be light! this new build has alot of changes in lightmapping code, and the engine is able to cache built lightmaps now. that is, no more lightmap recalculation on each game load. also, no more engine crashes on big maps with alot of dynamic lights (this could happen, for example, on a map with open space and hordes of imps, all throwing fireballs).

the new code is experimental (as always), but hey, everything in k8vavoom is experimental anyway. ;-)

also, i switched to GCC 9.2, because GCC 5.4 is unable to build k8vavoom code (internal compiler error, no less!)

WARNING! networking code is completely broken for now. i know it, and i will try to restore it later.

* oops: "zmapinfo" was never used due to a typo
* partially implemented "sky_exmx" hack (thanks, steinkrauz)
* alot of meaningless code changes nobody will notice anyway (tech debts, cleanups)
* always sort weapon slots (otherwise overridden weapons can be put into the wrong place, regardless of Weapon.SlotPriority)
* added "DOOMWADPATH" envvar support
* it is now possible to change weapons after morphing/unmorphing
* the engine will prefer Shadow Volume Renderer for "autoselect" (if it is supported by GPU)
* added "am_show_keys_cheat" automap cheat cvar
* added "am_keys_blink_time" automap cvar (so known/cheat keys may blink for better visibility), and UI menu option
* added option to draw DoomGuy face in horizontal screen center in fullscreen HUD
* better masked wall rendering in lightmap mode (there should be no more occasional "fringes" on masked walls... i hope)
* more VavoomC gfx API (rects and lines! yay!)
* some small optimisations in shadow volume renderer code
* slightly faster lightmap chain rendering
* better lightmapped surface management; the engine should not bomb out with "surface cache overflow" anymore (experimental!)
* implemented first draft of lightmap cache (both for initial map loading, and for savegames); it is not finished yet, but sometimes it works ;-)
* added optional BSP lightmap tracer -- see Advanced Video Options (BSP lightmap tracing is ~3.5 times slower than blockmap, but produces less light leak artifacts) (thanks to TerminalHash for test maps)
* perform partial lightmap atlas updates (in theory, this sends less data per frame to GPU)
* fixed glitch with glowing walls in lightmap renderer (missed some glow parameter updates sometimes)
* made stealth fist and chainsaw modes optional
* added some more "compat_XXX" tokens to mapinfo parser
* some 3d floor rendering hacks (garden fences in Golden Soul MAP01 should not glitch now, for example)
* fixed dynamic sprite lighting bug for lightmap renderer and 3d floors
 

and of course right after i pushed the last build, i made D4V.wad work without hidden CLI args, and fixed "floating corpses" issue with it. maybe it worth a minor update. we'll see. ;-)

and some PR: two quite huge maps (WIP), k8vavoom version of the first map is lit mostly with dynamic light sources: topic. very impressive effort, especially for a novice mapper, i believe.

...and found some bugs in new lightmap update code. quickfix is coming soon. don't worry, i'll try to break texture mapping to compensate lightmap fixes.

quickfix is so quick! at least it took less than 3 weeks. so, enjoy the new build!

* made iwad search case-insensitive (thanks, TerminalHash)
* sprite offset fixer will use real pixture height to calculate offset (this fixes "floating corpses" in some mods)
* added some decorate hacks to load "D4V.wad"
* added workaround for (common?) mapping bug: creating 3d floor by tagging all sector lines with "set 3d floor" special
* some hacks for 3d floor sprite lighting (still not right, tho; i should rewrite that thing from the scratch)
* added experimental code to put wall decals on 3d floor sides
* small rendering optimisations (better texture grouping)
* added experimental "VidRendererRestart" console command, to restart level renderer (so you can change renderer without save/load)
* several fixes to new lightmap code (occasional missed lightmap atlas updates on light-heavy maps)
* fixed bug in `FindShortestUpperAround()` (missing `!`)
* partial (and probably wrong) implementation of "$playercompat" (thanks, id0)
* added GZDoom weapon name tags to language file (thanks, id0)
* added hack (EXPERIMENTAL!) to prevent shadow volume z-fighting (thanks, TerminalHash)
* various small fixes for some obscure map hacks
* update only one camera texture per frame, and limit camera FPS (camtex update is slow, this speeds it up)
* use smaller render buffer for camera updates (it is MUCH faster than using main render buffer)
* light filter for shadow volume renderer can ignore manually placed static lights now (and will do that by default) (thanks to TerminalHash for the idea)
* fixed bug with stuck ceiling crushers (and some blocked doors) (thanks, id0 and steinkrauz)
* some fixes to 3d model rendering (translucent models in advrender)
* reworked OpenGL texture manager a little (should be marginally faster, but there may be some unnoticed bugs)
* fixed bug with user-defined out-of-actor constants in decorate
* allow hex literals for floating constants in decorate/defscripts
* alias (3d) model renderer was ignoring offsets if scale wasn't set
* it is now possible to shift alias model (shift is applied to world position before rotation, scaling, and offseting)
* better implementation of transparent door hack (TNT MAP02 doesn't glitch now) (thanks, steinkrauz)
* implemented arguments for `A_M_Saw()` decorate action
* added autoload processing from "~/.k8vavoom/autoload/<gamename>/" (non-windows)
* slightly better floodfill bug detector (still not right, but should be a little better ;-)
* it is possible to use "-autoloaddir" (even multiple times) to specify additional autoload dirs ("-autoloaddir /path/to/dir" will be used as "/path/to/dir/<gamename>/")
* show keys on automap in am_cheating mode >=1
* new, and more reliable (i hope) "-k8runmap" map detection code
* added experimental screen transition code (activate with "r_wipe_enabled 1"); please, note that this is not a final implementation, it is there only for testing!
* added autocompletion for aliases (thanks, TDRR)
* it is now possible to select different colormaps for invulnerability and lightamp

Thanks Ketmar!!!

let's hope that i won't find some Really Bad Bug right after uploading. ;-)

25 minutes ago, ketmar said:

* update only one camera texture per frame, and limit camera FPS (camtex update is slow, this speeds it up)

Oh does k8vavoom have support for rendertextures? interesting, also can these things (amount of camera textures available per frame and camera texture fps) be available in the console or via mapinfo or something?

Also is there any good vavoomc documentation yet?

1 minute ago, therektafire said:

Oh does k8vavoom have support for rendertextures?

cameras were possible even in the original Vavoom, i just made them slightly faster. not as fast as i want them to be, though (the engine still has to perform a roundtrip GPU->CPU->GPU for cameras).

3 minutes ago, therektafire said:

an these things (amount of camera textures available per frame and camera texture fps) be available in the console or via mapinfo or something?

for now it is hardcoded. sure, i can move hardcoded values to cvars, but i can't think out a reason why. ;-) but i also cannot find a reason to not do it. will prolly do then.

6 minutes ago, therektafire said:

s there any good vavoomc documentation yet?

alas. the language itself is quite standard c-like strongly typed OOP. but considering that basically the whole game is done in VC, the documentation should have all methods described, with their limitations and such. this is a huge amount of work. and i also like to change game internals from time to time.

VavoomC can be a killer feature for the port, but i am still not sure if it is the right way to go. like, it is absolutely impossible to implement VC support in other sourceports. exactly like nothing except GZDoom and its forks could have ZScript implemented. so i still think that people should better use decorate, and maybe ask me to add more decorate actions (which could be implemented by other sourceports) instead of writing VC code.

Hey, your prety voom doesn't run on win xp. I loved original vavoom for it's quake1-style software renderer and for nice cross-platform code, running even on win98. What the hell is it now?

win xp is EOLed, therefore it won't be supported. besides, windows is not even the primary platform for k8vavoom: i don't have windows at all. you may try to build k8vavoom with MSYS/MinGW for your OS, but i definitely won't jump through hoops to support long-dead system.

oops! i accidentally static RGB lighting. uploaded a quickfix, as it is impossible to check the map lighting with the broken lights. ;-)

* added guards for some sector flat move actions (thanks, steinkrauz)
* some hackery to not render invisible sector floors in Doom II MAP01
* alias (3d) models: fixed some possible bugs with interpolation; also, it is now possible to assign only one submodel to sprite frame
* it is now possible to attach more than one 3d model to sprite frame (required for better MODELDEF support)
* some fixes in GZDoom MODELDEF parser (it is possible to attach more that one model to sprite frame in gz; sigh)
* made pcx loader less strict (some software creates non-compliant pcx files for model textures)
* it is now possible to toggle 3d models for various entity types separately (like you can do for sprite shadows)
* scale some FS HUD icons (medkit, keys, ammo, armor); also, fixed typo: "bersek" -> "berserk" (thanks, id0)
* oops, static rgb light sources were spawning white lights too (due to inheritance changes) (thanks, TerminalHash)
 

oops. fix for extra floors for MAP01 broke some lowering sectors (those with sky ceilings and initial zero height). will be fixed in the next build, but for now if you'll see such glitch, it is enough to restart renderer with "VidRendererRestart" to get rid of it. sorry.

so, my first attempt to implement bloom (of course, it has some knobs for you to play with).

...and i thought, "why not?" new build for ya! you can turn on bloom in video options, the effect has its own submenu. there are some knobs to mess with too. don't forget that you can press "backspace" in menu to restore default option value, so don't be afraid of changes!

* fixed invisible floors due to zerosky hack (D2/MAP01 workaround) (thanks, steinkrauz)
* moved map rendering hacks to separate option submenu
* added option to turn on/off "zerosky" hack (description in map hacks submenu)
* fixes to 166 and 186 BOOM line specials (not completely right, but better ;-)
* map and lightmap cache file times will be updated on successfull cache loading, so caches will survive longer
* implemented bloom postprocessing effect
* "-skip-dehacked" option works again
* fixed some dehacked desyncs (i changed some default actors, but forgot to fix dehacked definitions) (thanks, id0)
* oops! i forgot that ACS scripts can setup new camera textures (thanks, id0)
 

with some help from id0, SHRINE final boss is now fully functional in k8vavoom. you still won't get the endgame text, though (this is due to somewhat clunky design of cluster text module), but at least the boss will not stuck with its hands raised. ;-)

this also may fix other mods with calls to `ACS_NamedExecuteWithResult()` when that ACS script is in turn calling `Delay()`. such scripts were immediately terminated by k8vavoom, giving them no chance to finish.

Holy cow! I missed out on a lot.

Now with bloom features!?

/me grabs the download..

59 minutes ago, Mr.Rocket said:

Now with bloom features!?

yeah. quite a cheap fx (in computational terms), and i wanted to implement it for a long time. because screenshots with bloom attracts more people (and jackdaws, i guess? ;-).

thank you!

33 minutes ago, Voltcom said:

But also runs very smoothly.

not as smooth as i want it to be, tho. but have no fear, my friends: i am working on making it even faster! moving renderer to separate thread is slowly progressing, for example. and when i'll finish with that, we'll have the whole frame to run game simulation instead of dividing it between playsim and OpenGL. this will prolly (i hope) give us smooth framerate even in most slaughtermaps.

sadly, i still don't have enough time to restore and improve networking. but i'm not planning to drop multiplayer, and sooner or later it will return, new and shiny!

p.s.: many zdoom/zandronum mods are running with k8vavoom too. and i am working hard on improved decorate support.

46 minutes ago, ketmar said:

this will prolly (i hope) give us smooth framerate even in most slaughtermaps.

"Damn, I'm looking good!"

Can't wait to see that happen, blowing everything up with fancy visuals :D . It's probably about time I finally try k8 but the one thing that kinda bugs me is the lack of stable releases like all the other ports do, which makes me feel like every new version is "beta quality" software. This actually sounds exciting now, rofl.

1 hour ago, seed said:

the one thing that kinda bugs me is the lack of stable releases like all the other ports do, which makes me feel like every new version is "beta quality" software

all other software is "beta quality" too. only i am honest, and don't try to disguise that with "release" label. like, 'cmon, modern games are often not even of "alpha" quality! ;-)

tbh, i am not a big fan of "releases". i am working on randoms things i like to do today (that doesn't mean that i don't have a plan/vision, it just means that there is no defined order for features i have in my plan/todo). when something is done, and i played with that new thing at least several days, i consider it "done".

actually, i have only one, but very dedicated GNU/Linux tester (thanks, man!), and zero testers for windows. so you can't expect anything better from "official releases" than you have now from my "public builds". actually, the less people downloading and playing with k8vavoom, the less quality is there. so you can make the engine better by simply using it, and reporting bugs. i cannot promise that i will fix all reported bugs quickly, but i'm taking notes, and sooner or later will fix what i can.

also, i am using k8vavoom to play Doom every day (because i started my fork not because i really wanted to code Doom, but because i wanted to have an engine i like to play Doom ;-), so crashes tend to be fixed ASAP. as for more decorate features and such -- i am progressing quite slowly, because most things i want to play either works "acceptably", or will never ever work anyway (like, they have zscript, or using some specific GZDoom feature i don't want to implement at all; or there are no public specs -- like for additional ACS opcodes and chunks, which i won't implement until The Official Specs will be written).

ok, tbh, this wall of text means "k8vavoom public builds are actually releases". ;-) i am trying to do at least one release per month, so people can follow the development. it is prolly somewhat unusual rate, but hey, why not? as k8vavoom is "minor" sourceport (in the terms of userbase, not features ;-), i feel that i have to give my users something new they can play with as often as i can. this is my form of saying "thank you for your interest in k8vavoom", i guess.

hm. and i though that i mastered revenant rocket avoiding technique. it's hard to describe just how wrong i was! now i fixed the bug that made state ticker skip some tics (i hope ;-), and found that those homing missiles are as deadly as they always were... i am almost ready to put that bug back again.

i think we'll get a new build soon. i want to try some intrusive changes (i won't speak about it more, because i don't know if it won't become a dead end), and i also have a big enough changelog (in case you wonder before, changelog size is *the* thing i'm using to decide if it is time to "release").

also, one of Heretic bugs @ReaperAA reported earlier wasn't just a small cosmetic thing, that was my royal fuckup with bitmasks, and it completely broke some mobj flags. yay. that's why every bug report matters! ;-)