k8vavoom: no good thing ever dies!

[Gez]

SLADE doesn't "love to create duplicate", it's a tool, it does what it's told to.

 

It does have maintenance features to tell you about duplicated names, too.

 

And it's not based on the ZDoom loader at all; it's based purely on the WAD format specifications, which are that duplicate names are not only supported but are in fact required to be supported since it's how maps work; while the ZIP part is built through wxWidget's ZIP class.

[ketmar]

it is a tool for people who mostly knows nothing about internal structure of wads and zips. so creating invalid zips and barely valid wads should be hard. user should be forced to turn on "expert mode" to get rid of checks, not to do something to perform those checks. that is how tools for non-programmers should work.

 

but tbh, i have little interest in talking about slade anymore. i won't going to fix it myself, and fix for zips for the next major release is not enough. so it will be broken for a long time, and i will be forced to keep workarounds for its files. while i am accepting it, sometimes i am so annoyed that it leads to public rant. sorry for that. i myself not free from errors and bad design too.

 

that is, slade is a good tool. the sole reason i am so enraged is that it is a good tool with some warts. i only enraged about things i really care about. yeah, i know that it is not the best attutude to get things fixed. sorry about that.

[ketmar]

so, to make this back on topic: i implemented PoC of checkpoint saves at map start, and it seems to work. it even autodetects mapsets with hubs, and silently reverts to full saves in this case. now i have to throw all that code away, and write it for real. ;-)

[therektafire]

never mind i'm dumb, is it possible to delete posts lol

[CorianderCastor]

13 hours ago, ketmar said:

that is how tools for non-programmers should work.

 

That's how we get wysiwyg (typically wysiwyg, but it's not inherently bad) garbage.

 

13 hours ago, ketmar said:

"expert mode"

 

especially since this is usually omitted.

 

13 hours ago, Gez said:

it's how maps work

 

This!

 

Also, cool engine. Glad to see a VaVoom I can run. It's historically significant and interesting too.

[ketmar]

44 minutes ago, PaquoCastor said:

Also, cool engine. Glad to see a VaVoom I can run. It's historically significant and interesting too.

thank you! i always thought that Vavoom is overlooked gem. i waited for years for someone to pick it up and continue developement, but nobody came. so i basically had no other choice than to do it myself. and it is great that people still remember Vavoom, even if it is just for some nostalgia or curiosity. ;-)

 

welcome, and i hope that k8vavoom will work for you. maybe someday it can even become your sourceport of choice. ;-)

[ketmar]

i am still not happy with checkpoint system (too much manual work), but let it be like that for now. it producing very small (~1kb if you're playing without alot of mods) saves that should survive most save file format changes i'd make in the future. it may glitch with some complex mod, but as far as i can see -- it shouldn't. sadly, Strife and Hexen are hub-based, and they're complex enough to be first targets of this feature, and oops. what a cruel world!

 

still, i am working on better save format. i remember my RAGE AND HAET when GZDoom breaks its saves, and this is the rare case i happy that k8vavoom doesn't have huge userbase. people will lynch me for losing their progress. ;-)

[ketmar]

also, just found and fixed "decorate loop replacement bug" (this is when one actor replaced several times in mod's decorate). smoothdoom does this, for example, and endlessly spawns "ImpDice" instead of real imps. the hard part is that if you'll load several mods, later mods should replace old mods replacements, not original -- this way mods can stack gracefully. but if one mod replaces the same actor several times, endless spawn loops are possible.

 

usually this is some kind of copy-paste bug in mod code, so k8vavoom shows all the relevant info to fix it:

Warning: DECORATE error: already replaced class 'DoomImp' replaced again with 'ImpDice' (current replacement is 'SmoothDoomImp')
Warning:   current replacement is at SmoothDoom-2018-12-18.pk3:deco/monsters/imp.txt:1
Warning:   new replacement is at SmoothDoom-2018-12-18.pk3:deco/variants.txt:99
Warning:   PLEASE, FIX THE CODE!

 

[ketmar]

heh. that last build was extraordinarily buggy: due to alot of internal changes many things are unreliable. even save/load can crash unpredictably (especially on fast SSDs). i am really sorry.

 

i already fixed alot of bugs and crashes, but i prefer to delay new build until i'll finish new save/load system. this is somewhat big task (i have to write a new chunked storage manager, a new named value manager, and rewrite almost all serialisation code), and it may took more time than i estimated. so if you found some bug in current build, please, wait until i'll upload a new one, and re-test before reporting. maybe i already fixed it.

 

sorry for inconvenience! (meh! nobody except me is using k8vavoom as their primary sourceport, so it prolly doesn't matter; but then, being polite costs me nothing ;-)

[ketmar]

things are slowly taking shape. most basic low-level parts of new save system are ready, and some even field-tested. serialisation of script objects splitted into independent "script data" and "internal engine data" parts, and internal engine data is going to be tagged with names and types instead of being an opaque binary blob. this way, order of values won't matter anymore, and it will be possible to both ignore old unused values, and get some sane defaults for new missing values (or skip some non-vital old data altogether). so if i'll change decal system, for example, the engine will either try to rebuild new decals from old data, or will simply skip decals part, but you will still be able to progress. that was already done for script objects (saves can survive many script changes), and now i generalizing it to all saved data.

 

of course, some huge changes (like missing classes, or radically changed internal class structure) will still break saves, but those changes are quite rare. for now i delayed some improvements partly due to non-flexible save format (it is not fun to break saves with each new build; besides, i am using k8vavoom to play megawads, and i don't like to lose my progress! ;-). hope that with new save system in place i will be able to change things more often (and easy).

 

also, new saves can be analysed without knowing anything about internal engine data structures at all. so if somebody will send me some save that exposes an engine bug, i'll be able to extract alot of useful info out of that save even if reporter's engine version is much older than the current developement one.

[Cambertian]

Lemme start by saying: hey, great work on this! The idea of Doom with Quake-style scripting/lighting has always been enticing to me, but I came too late to the party to make use of it.

 

My only disappointment is that I don't see any evidence of a software renderer, re-implemented or otherwise, which was half of the charm for me... I'm not going to actively ask for it because I know it's too much trouble, but I'd like to show my support for it if it's ever put on the table.

 

Regardless, I'm excited to see future developments. I wish you luck!

[ketmar]

thank you!

 

software renderer was eliminated by Janis himself in the latest official release of Vavoom. and, by the way, it was almost the same as OpenGL renderer with turned off texture filtering (there are options in k8vavoom to toggle filtering of textures and sprites). the only difference is fadeout tables (to simulate light fading), afaik. sure, it doesn't look exactly as software render, but this is the best you can get now. sorry.

 

alas, (re)implementing it again is too much work. it is possible, but i have many other things to do, and no other devs to help me. so sorry. due to lack of resources i eliminated legacy OpenGL renderer too (so you need at least OpenGL 2.1 with GLSL 120 support now). if i ever get a team of developers, though, software renderer can be brought back: it is still interesting task, even in GPU times. ;-)

 

thank you again, and welcome! i have gross plans for k8vavoom, and we're only started. i'll take over the world in the end, so stay with the future winner! ;-)

[ketmar]

WARNING! this is interim build, so you can run something less buggied (i hope ;-) than the previous one while i am still working on a new save system.

* better pwad texture lookups for animdefs
* more fixes for invalid PWADs produced by slade
* added missing animated textures from DooM II / Ultimate DooM
* decorate: added support for sprite billboarding flags
* oops; i accidentaly sprite renaming, so Strife was broken
* skip map entering autosaves for single-level pwads which replacing MAP01 or E1M1
* implemented simpler and faster checkpoint saves on entering new map; it may not work with some complex mods, so you can turn it off in "misc. options" menu
* added `A_FireSTGrenade()` decorate action
* fixed bug with `CallACS()` from decorate (i broke it with transitioning from script thinkers to script lists)
* added workaround for multiple replacements of the same actor class in one mod (so SmoothDoom is working again)
* added some more diagnostic warnings for obviously wrong decorate code
* gore mod: it is now possible to force colored blood on bruisers and cacodemons (for mods that doesn't do that) -- on by default
* decorate: generate optimised VM code for `A_Jump()` (and allow up to 255 labels, wow)
* better controls menu, with all "hidden" keys exposed; also, special Strife keys won't interfere with other games anymore
* fixes in ACS loading order (it should be more reliable, and should fix some ACS string misindexing)
* added handling of some special requests in ACS `PrintName` opcode (level name, etc.)
* added "autoload.rc" with wad/pk3 grouping, and "-skip-autoload <groupname>" to skip some autoload sections (see git commit 49217bbdd7116d for some documentation)
* added custom game modes (lists of pwads to load, and autoload groups to ignore; see git commit 33da1e3c394593e)


with the following examples, you can use "vavoom.exe -mode smooth", for example, to run "SmoothDoom config".
sure, this can be done with dedicated launcher, but hey, i am not using launchers! ;-)
 

example of modes.rc (should be placed in "share/basev/doom/"):

Spoiler

mode "smooth" {
  // this will load pwads before "-file"
  // use `postpwad` command for pwad list to load after "-file"
  pwad "/mnt/vavoom/SmoothDoom-2018-12-18-fixed.pk3"
  // skip autoload groups from "autoload.rc"
  skipauto "smoothwpn"
  skipauto "spritefix"
  // options
  DisableBloodReplacement // so gore mod will be in effect instead of SmoothDoom one
}

alias "smoothdoom" is "smooth"
alias "smooth-doom" is "smooth"


mode "min3d" {
  skipauto "models-weapon"
  skipauto "models-decoration"
  skipauto "smoothwpn"
  skipauto "spritefix"
}

 

example of autoload.rc:
(should be placed in "share/basev/doom/autoload/", and corresponding subdirs/pk3s should exist)

Spoiler

group "models-weapon" {
  models/mdl_weapon.pk3
}

group "models-ammo" {
  models/mdl_ammo.pk3
}

group "models-items" {
  models/mdl_items.pk3
}

group "models-keys" {
  models/mdl_keys.pk3
}

group "models-decoration" {
  models/mdl_evileye.pk3
  models/mdl_fskulls.pk3
  models/mdl_pillars.pk3
}

group "models-barrels" {
  models/mdl_barrels.pk3
}

group "models-gibs" {
  models/mdl_gibs.pk3
}

group "smoothwpn" {
  smooth/pk_anim2_black.pk3
}

group "spritefix" {
  sprfix/D1SPFX19.WAD
  sprfix/D2SPFX19.WAD
}

 

[ketmar]

of course, working on new save system cannot go on without new internal node builder. so i imported zdbsp, and now k8vavoom has two internal node builders for you to choose: ajbsp and zdbsp. zdbsp is default now, as it is alot faster, and does slightly better job on UDMF maps.

 

and if you wonder why new saves require new node builder, the answer is: more pepper! and a cat is fine too.

[ketmar]

...and reverted it. zdbsp builds absolutely defective strange segs my PVS builder cannot understand. as i don't yet know what is wrong, i cannot detect/override that, and i need PVS. so back to ajbsp as default builder, and zdbsp is marked as "experimental and unreliable".

 

"strange" segs seems to be related to deepwater/flatfill hacks. looks like zdbsp does something special with them for some reason. as PVS is used everywhere in the engine, and turning it off will slow down many things, zdbsp has to go. at least until i have time to do a proper investigation.

 

p.s.: zdbsp left as an option for those who will turn off PVS. the engine will still work without PVS, and some people may prever it that way. turning off PVS will (somewhat) slow down LOS and dynamic light calculations (among others), but people with fast CPUs may not notice any difference. after all, built-in PVS was not present in the original Vavoom. ;-)

Edited January 29, 2019 by ketmar

[ketmar]

well. it seems that i thought out a workaround for zdbsp. i don't have a time to investigate it properly yet (if i'll drop my working plan for more than a day, i will not complete anything ;-), but it seems trivial to implement, and should provide a temporary "repair" for PVS for now. at least i hope so -- i still have to implement it, and see if it works. working PVS (even it its current primitive form) is a vital part of the upcoming "unified lighting system", but i don't want to drop zdbsp too -- it is too fast to be rejected.

 

anybody knows cheap cloning facility, so i can order some more ketmars? i really need them! ;-)

[-TDRR-]

Just now, ketmar said:

anybody knows cheap cloning facility, so i can order some more ketmars? i really need them! ;-)

Maybe you can try training a neural network to act like you and write code? And call it "Neumar Ketwork"

 

DUBG is starting to shape up in Vavoom, the only thing left now is fixing TEXTURES and we are golden! Thanks for your efforts on continuing Vavoom.
 

[ReaperAA]

3 minutes ago, -TDRR- said:

DUBG is starting to shape up in Vavoom, the only thing left now is fixing TEXTURES and we are golden! Thanks for your efforts on continuing Vavoom.

 

DUBG?

[-TDRR-]

Just now, ReaperAA said:

DUBG?

https://zandronum.com/forum/viewtopic.php?f=58&amp;t=9493

It's just a little weapon mod that i did. Includes stuff like Vehicles, a small filesize and blast jumping with a SSG.

[ReaperAA]

Just now, -TDRR- said:

https://zandronum.com/forum/viewtopic.php?f=58&amp;t=9493

It's just a little weapon mod that i did. Includes stuff like Vehicles, a small filesize and blast jumping with a SSG.

 

FUUUUUUCCCC. I knew some maniac would do something like this in near future. Didn't realize it was already done.

[ketmar]

...and while investigating zdbsp issues, i accidentally found some anomalities in stacked sectors rendering code. that's why i didn't want to open that can of worms. now i see how it can drop your FPS to literal zero for some reason, and just cannot leave it as that. the bad thing is that i never really looked into special cases in rendering code, so i have to decipher it first. it does some strange things i cannot understand (like, why it was done that way? some future plans, or just "meh, it kinda works"?). and i really need in-engine UI to inspect some internal structures (instead of dumping them to disk, reparse, and basically rewrite the renderer as standalone thing). dammit. looks like it is time to shuffle my feature list somewhat, and move tools to the top.

 

didn't i told you that i HAET working with graphics? i am a compiler guy, i love writing compilers, not renderers! 'cmon, hell forces, if you will send me some of your guys to help with the code, your portal to Earth will work much better! and i will break Doomguy's guns, so nobody will stop your invasion this time!

[ketmar]

of course, i couldn't just leave it all alone (or do what i was intended to do, for that matter). so i workarounded zdbsp with forcing PVS off for it (you prolly won't notice any speed difference with or without PVS yet, so why not -- and loading levels without PVS is MUCH faster). and while i tried to investigate other zdbsp issues (not yet), i found that closed doors and raised lifts were never acting as clipping solid walls. yay. i am almost never using automap, so it went unnoticed for a long time. also, i found one typo in sector transfer code, so some previously glitchy maps should render much better now.

 

i also removed all legacy copypasta from clipper code: there is no reason to "help" compiler with manual code copypasting these days.

 

some rendering code is starting to make sense now. there are still "wtf, Janis?!" parts there, but i hope to make it all better. now i really have to finish new save system, lol. it is quite boring at this stage, so i am... procrastinating, i'd say, by touching other, more interesting engine parts.

[ketmar]

we (i and the engine) are not dead yet. made some fixes to renderer (some for better, some... ugh), ui, keep going with save code conversion. here's small image for you all. nothing special, just a lucky random screenshot.

Spoiler

 

[3t0]

It has been some time since I have been on dooming spree like these days. Game engines, especially underdogs like Doom, Quake, Cube, Sauerbraten are fascination of mine. It's on and off thing for me. And I am now in one of such phases, thus this will be long so please, bear with me. Or not. Your call.

 

BTW/ bullet points are "kinda questions to answer" by somebody.

 

Long story short, I wasted quite some hours recently with some of these elder games of yesterdays. After learning about ZDoom's unexpected death and playing few days with GZDoom, I decided to give a ride to few "other" vehicles. One of them was Vavoom. I did not know what I was getting into, though.

 

I am "GLOnly" die hard type and I don't consider software renderer important anymore. I mean sure, it's cute that some consider it pinnacle of purity, and themselves purists, but: if you want to be "pure", get DX4 with actual phosphorus screen, put DOS on it, and have your pure experience with old exe. Otherwise you are just lying to yourself, pretending, as times have changed. These days even phones have OpenGL you know?

 

I started with "pure" on 486 and Pentium and lost so much time with it does not even register anymore. After burning my and friend's monthly allowance together on copy of book of "Doom strategy" with DEU on a CD (none of us had reader - but we managed through third friend), I quickly hit visplane overflows and internet was not yet (in my country at least), eg. to get source ports.

 

Over time I became all OpenGL (because it works perfectly everywhere, maybe besides shitty Windows and looks really good), WSAD, +mlook, noautoaim guy who loves UV (old oned - current UV wad authors are serious madmen) and very sporadically some NM in first levels of D2.

 

"Pure" Doom with fixed yaw feels like shit to me these days, so much for it. I love how my doom experience only gained and I lost nothing. If I wanted purity, I would just dust that old 486 in basemented (it works perfectly till these days). I want fluidity software cannot easily provide, that's why I play source ports.

 

So back in actual land of GL ports, situation seems rather stagnant, or stable, maybe even stale? Well "everything as usual". And don't get me wrong, I consider that a very good thing! STABILITY IS A GOOD THING. You can build on stable. Not so much on the opposite.

 

But there is something else besides stability I am interested in and care about, and it's related to the future.

 

But I wouldn't call that futurething of interest "modernity" though. Everyhting I learned about "modern" is, that it is old bullshit that somebody is trying to sell you as cool new shit, but it still the same shit as always, maybe only sideways. And I am not even that old.

 

The thing that I really care about these days is progress!

 

Now. Now. That good old progress. It is something different then "the modern". Progress usually loves to take it's time and you cannot just readily see it. You have to evaluate it agaisnt that time it took. See thing before, see same thing after some time and only then you can gauge progress it made.

 

So overall, in source ports land, I did not detect much progress.

 

Doomsday is relatively good looking, traditionally, heavy as shit, as always, having weird ass launcher (is it here or not? I never can get that crap to build) or something pulling in dependencies on stoopid packages that game should never need. It was cool, when it gained fake radiosity and flat glows some time back, but besides frollicking with UI and menus it did not made much observable progress in recent years. Internally maybe, but who knows?
 

Now other ports are nowhere near as complex and feature-filled as GZDoom is. That one seems constanly ahead of the pack, most single player and mapper/modder friendly source port there is. Rock solid, but there are occasional stutters sometimes. Story-and-feature-wise all wads I tried work. "New" portals tech is very cool, full GPL compliance too, so much progress, as usual!
 

PrBoom+ felt most "vanilla-like" (not that it matters to me), but both the +mlook and movement feels fucked up. I haven't noticed any real progress. Not bad. At least it's stable.

 

EDGE/Hyper3DGE always seemed pretty dated to me visually, despite it being quite powerful and most daring to progress. Yet for some reason I am getting black layer of blinking shit around any 3D floor platform in EDGE demo maps (circular room with moon and such). Also the slight quake-like roll to side when strafing, with wobbly steps, doesn't feel right in most levels, vanilla or not. But I can imagine it might be cute for some kind of mod though. There was certainly some progress, but I don't feel it.

 

With Zandronum, that still rules at multiplayer for me, all other ports like Risen and others, are trying hard to survive in their little pockets of community, but are more or less similar. Not perceiving much progress.

 

Then, I suddenly remembered there was a doom port with light-mapped environments.

Lightmaps in 2.5 Doom? Now that is some serious progress! I wanted to see that.

And after some time of thinking really hard I even remembered the name: Vavoom!

 

I always considered it intriguing. But, in the past, I never had a good luck with it.

 

Each time I tried it, it was stuttering like shit and generally felt very unstable overall. Like ready to tip over at any moment. But that was ten years ago. Maybe progress happened and things got better!

 

But no! Reading of wiki and searching the net showed, that it died unexpected death, seemingly. I was so sad!

 

I wanted to try it, to gauge progress it made! But we didn't even had a chance!

 

Well, but sometimes, I am persistent maggot and was willing to give it a try anyway.

I really wanted to, given I never had much fun with it in the past, and I really wanted to see ligthmaps in Doom.

 

As I refuse to muck around with outdated binaries in vms (or wine), and source is open, I checked out the repo from what seemed to be canonical upstream (there were even some spurious commits logged until recentlish - huh, so there might be a chance it will compile, I thought).

 

Once checked out, for shit and giggles, I tried to compile it right away. This is on relatively modern distro, Void Linux, my daily driver. Despite not being the teenage edgelord of nerdy Archers, it is not completely stale piece of shit that Debilians and Boobuntus are, and so it has been some time already, since extra shitty GCC 8 landed here (to immeasurable joy of many, I presume).
 

<siderant>

Why "for shit and giggles"? Well ...

 

I learned myself some bits of C in recent years (nothing ground breaking though), and one thing I came to believe, based on that experience, is that C++ is fucking disaster. An abomination that should have never ever existed and as soon as it appeared it should have died. Yesteryear was late. C is definitely more robust thing than C++ can ever hope to be.

 

Don't get me wrong, OOPy shit and C++ features might be sexy for you as a coder (or maybe not), but there is one thing that I am 100% sure and that can be 100% empirically proved and confirmed by anybody willing to and that is that C++ is fucking disaster for the user!

 

 

And I don't give a fuck about what hipsters are saying about how boost shit and C++ 2025 geriatrics, or what, are gonna save us all. Reality is, that not only we have army of shitty C++ compilers (MSVC, gcc, clang) of which not a single one does same things right or at least same way as any other, but any C++ code compilation is essentially "onetime" affair: Fact that something in C++ compiled yesterday is completely tied to that moment, it does not mean it will compile tomorrow. It means just that "it compiled" (today) and nothing more, and nothing less. You cannot know whether it will compile in the future. So much for stability. Also no real progress. But C++ is definitely modern.

 

 

Tsssssh, I will tell you a secret everybody sane knows, but we don't talk about it much. C++ is in fact pseudo random error generator. And GCC is, by far, worst offender in that. At least in my personal experience.

 

Case in point: I have some old toy C++ engines covered in dust, lying in storage, like Quake3 BSP loader demo that I found onnet in 2005. Things like that are essentially impossible to compile these days. And what's worse, they are impossible to fix yourself as well, at least, unless you are C++ guru, that is. And if you are that much of a C++ guru, then it's already too late for you. You brain has been C++-ified.

 

 

So take a note, if you see some 1 month old C++ code, only way to tell whether it will compile is to try it. But there is 90% chance it won't work, though. So don't bother. Electricity is expensive resource :).

 

Funny thing is, that in the mean time, even several years old (though revised) K&R C examples from the book I got as gift from brother, will compile today just fine and probably will do so even in following decades, aka future. And they will bring us progress, and should that compile once fail, there is still sizable chance you will be able to fix it yourself, as mere user, just by reading compiler error output. No "modern" randomness of the day.

 

So when I saw quite a few .cpp's in vavoom's checkout, I knew it will be "for shit and giggles". But one can have dreams ... or not?

</siderant>

 

Thus I started the build ... and, unsurprisingly, after one zilliard of undecipherable C++ random error messages "of not cool enough", probably about vavoom not being following proper C++ fashion du jour, the build died on something fatal.

 

I tried to muck around with letters for a bit, moving them back and forth, but as expected, it went nowhere, and I had to give up on vavoom once again. The one, I never got the chance to try out properly!

 

I have to admit, there were tiny tears in my eyes. Feels.

 

Next evening, still refusing to let go, somehow, this thread finally got into uncle Gees database of my personal filter bubble (asshole probably saw me searching for Vavoom stuff like mad), and I found this fork. I was really excited, holding my breath.

 

I did:

git clone blabla k8vavoom.git

cd k8vavoom.git

mkdir build

cd build

cmake ..

And watched percents scroll by ... and ... besides single something not fatal ... it compiled!

 

I could not believe my eyes!

 

Then me and k8vavoom fought a bit about command line arguments ...

 

• Regarding that thing, first note: please make k8vavoom understand '-h', '-help' and '--help' so it says something meaningful instead on insisting that I forgot to specify IWAD dir. Incantation synopsis with list of arguments supported would be really nice.
• While at it, teaching it '-v' and '-version' would be cool too.

And finally with all path and game args supplied ... it consistenly died on me with:

 

 

So close, so fucking close ... This cannot be!

Did I say I am maggot sometimes refusing to give up?

 

Such was the case now and so it all started. I reset build dir several times, zapped and checked out the tree, moved around in last commits with full, in-between, zaps, trying to find out whether something did not break WAD/PK3 access on my system - but no avail.
 

Finally reading the old readme, I noticed that engine was always built in place, inside the tree. So after another full zap and:

cd k8vavoom.git

cmake ..

... it worked! One magic invocation later I got to Doom screen! I was joyous!

 

• Regarding that, are not out of tree cmake builds of k8vavoom supported?

Finally we got to have some one on one quality time, me and k8vavoom!

 

After some mucking around with resolutions, due to my multimon and keyboard bindings, I got nice stream of classic "vanilla" dooming up to "Trick and traps", when I got bored.

 

Vanilla worked great! What surprised me most was overall stability and swiftness.

 

Engine didn't seem unstable one bit! What I was most pleasantly surprised was great doome-y movement with perfect quake-y +mlook. This port's movement definitely feels best to me so far! Also apparent framerate seems very very consistent and fluid, no peaks or lows...

 

• Is that your doing, ketmar or was Vavoom always like this?
• Or it's just that hardware is so overpowered these days that vavoom feels great?
• On that note it seems that built-in developer FPS counter is permanently stuck at 90 FPS for me, unless it drops, that is (more on that later)...

 

But I wanted to see two Vavoom killer features the most: 3D Floors and Lightmaps. I wanted to see progress.

 

Dling and running official demo level first, left me a bit lukewarm. Slopes in first room and 3d floors in another, both were totally fucked up. So much for good swift engine....

 

But reading this thread before, I remembered ketmar had some problems with zdbsp, so I switched back to ajbsp, and voilá, level was playable again!

• So question is why is zdbsp needed, why bother with it? (due to mods?)

Speaking of FPS, those seemed to be locked to 90FPS, and if they are, I certainly missed something and am sorry for bringing it up. Anyway with stencil lightning FPS tanked drastically to around 40 FPS in certain angle.

• Does it mean that "new" lightning model is still very unoptimized, or that is realistic cost it has?

Last thing regarding demo, map besides some architectural scale issues, it worked as adveritsed, albeit lightmaps were looking like crap. The whole map is really bad, but i discovered some rather serious issue with vavoom:

• Water handling is uber tragic!

Seriously, I was studying it big and is disappointing

• First, when you jump into the water, you sink. That is normal, but it is not happening normally here. You sink like a rock! I guess armor and all those weapons and ammo are pulling you down like mad :).
• Second, it is virtually impossible to get out of the water normally, by reaching the edge of the pool and getting out. You can jump (not) and you can rub the linedefs, but you cannot simply get out of the water in Vavoom (at least I can't).
• But then I discovered you can actually jump out of the liquid by doing small "curvedive"! First you reach the surface, then you mlook down to bottom and do small dive, that while holding "run" (or on autorun). When you reach about a meter of depth, you then mlook back up, surfacing. This movement gives you sizable momentum, so when you penetrete the liquid's surface you will fly out of the water with speed of the rocket that is following (impossible) parabolic trajectory. This is ridiculous!

While I have to admit I have lost too much time to count jumping in and out of the water tank in demo map, and that it is quite funny thing in it's own way, this waterborne behaviour is just silly. Especially since you cannot simply climb out of the water at edge of the water body, no matter what (or it is really hard). Sinking down at a speed of freefall doesn't help the case either. It bears to mention, that actual moverment in water is superb: back-forward-strafe and mlook wise it works great, albeit too speedy.

 

What I suggest:

• As this funny water mechanic is rather funny, I believe it should be preserved for posterity. I suggest cvar g_funny_water, which if set maintains this exact behaviour.
• Then I suggest to add check in the engine that when you are surfacing from the water to stop you at the water surface level, maybe allowing small wobble even but no straight "jump out". I believe player's momentum should be removed or severly dampened when reaching water surface from bottom (top one that is). This will stop the incredible "dolphin jumps" out of the tanks.
• Then I suggest to add bigger sideways up/down movement friction while in water (this will prevent player from gaining impossible speeds while waterborne). You cannot swim faster than you can run or jump.
• Then gravity needs to be seriously dampened in underwater scenarios, especially when idle. Sinking speed of Quakes, Half-Life or Saurbraten should be emulated. Water does not feel like water if one just falls through.
• Finally, climbing out of the water at the edges of the tank needs to be fixed. You should be able to climb effortleslly out of the liquiquid but only near 2 sided linedefs, where adjacent sector is not too high (maybe at maximum stair height?). Without this it would be impossible to get out of the water once dolphin jump becomes impossible.

Where this should be fixed, I have no clue. Is it in VavoomC part? Or in C++ parts?

 

Maybe it would be good to have some tweakable "liquid movement model" with flags like "can jump out through top surface", "can climb up at edge", and properties like "antigravity friction (buoyancy?)" and "movement friction (viscosity)".

 

The point is not to have physically based model, these are simple additive/subtractive values, similar are used for effects Doom already does, so intent would be to add only something simple, relatively similar what we already know.

 

With such "model" in place, perhaps for all actors, it would be possible to have some default values, for say water, that are active by default when thing is underwater, and then maybe have Thing that mapper can place into the "water" sector to tweak these values. High "buoyoancy" and high "viscosity" would create something "thick", and paired with "lava" texture, sector damage and thick traslucent red color inside of the sector, one can create really nice "lava pit of despair" which is really hard to get out of. Once actor would enter normal sector the model would be deactivated completely. There even seem that something like that is already happening behavior wise (current water seems to increasing friction a teeny teensy bit), but it's very unnoticeable. Well sorry, this was just a thinktrain I got into, being tortured by Vavoom's water for some time (everywhere not just demo map).

 

After playing jumping out of water in the demo I got bored. I wanted to see more of the lightmaps. So I searched for all the vavooms wads I could find and tried them all: Slayer's, Whispers, Storage and Silent Steel.

 

Now finally I saw the progress. Lightmaps, aka static lights, are absolutelly stunning (relatively, eg. that is for doom engine), very Sauerbraten-y (I guess due to lightmap renderer constraints of being level load time eg. online). Demo map does not give the engine enough justice.

 

Atmosphere and ambience of the properly lit levels was phenomenal and combined with 3D floors I was finally experiencing something new. 3D floors felt rock solid, I never got any glitch. Slopes were bit hairy and water was awful. Combat was superb especially on bridges and such. It all felt very quake-y, looked gorgeous, and unlike in Quake, I had great automap (which is also very tastefully done). Only problem I have with the wads is, that there is too few of them.

 

I must honestly say, I was flabbergasted.

 

Full disclaimer: I am one of those weird guys who considers lightmaps superior to anything, and stands by it. I think the one reason why even young kids don't laugh at Quake 3 is that is uses lightmaps. You can be completely inexperienced, you can be dumb, but you cannot fool a gut feel, that lightning cues provided by global illumination techniques like radiosity provide to yout vistual cortex. They simply look "realistic".

 

Modern game lightning is shit. Most of it are hacks. It's basically simple sharp point lighning fom 90s with pile of hacks to not look so sharp. Real world light is much softer. Lightmaps can provide that. But.

 

Ask anybody raytracing architecture, how much it takes to trace proper GI for a scene, and ee are talking about hours if not weeks of constant 100% all core and memory tortures. That's the price for soft "leaking" lights.

 

And that's how long qlight phase took on some crazy maps, we were making when Quake came out and when both algorithms and machines were shitty as fuck. Today's q3map2 is pretty good gauge of progress we made since then, and although it is somwhat dead, still more people are baking lights into the models in unities and blenders.

 

Static lights are superior because they are offline, can be pre-computed expensively using most complex algorithms and then be reused quickly and repeatedly.

• So one of my nest questions is: would it be possible to have calculated lightmaps stored in lumps of map's wads itself? Currently it seems engine recalcs them each load.

Lightmaps have only two disadvantages: they are static, so nothing in the world that is casting a shadow can ever move and they consume memory. I think Vavoom hits sweet spot in both looks and efficiency. After all it's ligthning model seems one of the simpler ones.

 

Some people say all this can be achieved in GZDoom and dynamic lights too, so if you know of any tastefully done wads like that here with them! I am quite skeptical, though, and so I want to see such result with my two bare eyes.

 

Anyway, great engine! If it is unstable as they say, I have not hit, it miraculously.

 

Thanks ketmar very very much for bringing it back to life. I hope you will maintain to maintain it :)!

[ketmar]

yay, it is huge! thank you for not only trying k8vavoom, but for writing your thoughts too. user feedback is always valuable!

 

now i'll try to answer some questions. dw forum software is somewhat uncomfortable, tho, and i may miss something on my way. don't hesitate to repeat any questions i missed. ;-)

 

6 hours ago, 3t0 said:

Regarding that thing, first note: please make k8vavoom understand '-h', '-help' and '--help'

it is quite hard to implement "right": due to legacy roots, there is no "central registry" for CLI args, so help cannot be build automatically. and i found it hard to decide which arg should be included. also, most sourceports supports standard arguments like "-iwad" and such, and i never realised that people may not know that. heh. it is hard to think as someone who is not at least knee-deep in sourceports. ;-)

 

that is, thank you. the engine surely needs some simple help, and simple README, so people will know what to do after they managed to build it. but you know how programmers love to write documentation (and even when they do, the quality is... eh ;-).

 

that is, i never thought that people may struggle with running the engine. now i know, and will try to write some starter docs. the same thing was with "game saved" messages: i myself never needed 'em, and never realised that people are playing without opened terminal, so they never see any meaningful messages. once i realised it, i immediately added HUD feedback. that's why i want to hear more user stories! ;-)

 

6 hours ago, 3t0 said:

This port's movement definitely feels best to me so far! Also apparent framerate seems very very consistent and fluid, no peaks or lows...

 

• Is that your doing, ketmar or was Vavoom always like this?
• Or it's just that hardware is so overpowered these days that vavoom feels great?

in lightmapped mode, Vavoom was always smooth. but hardware plays a big role too: back than, level loading with all lightmap building was quite long, and putting alot of active enemies onto a map will slow the engine down (this is still a problem i will solve one day).

 

so the answer is: it is mostly Janis work, and hardware power. i am mostly improving VaVoom C compiler, fixing bugs, and doing small optimisations. i have plans to write a new renderer (much faster, with possibility to utilize free CPU cores, and such), but it is something that is still in experiments stage. so -- thanks goes to Janis.

 

6 hours ago, 3t0 said:

On that note it seems that built-in developer FPS counter is permanently stuck at 90 FPS for me

yep, framerate is capped at 90 FPS. tbh, there is little reason to have more (i think), and there are some other reasons. the main reason is that Vavoom is not lockstep-based. i.e. most sourceports still does 35 FPS internally, and interpolates for higher FPS. but Vavoom is not locked at 35, it is using time delta to calculate various fractional values. that is, Vavoom is smooth (almost) without cheating, and there is no code to interpolate movements. but this has some price to pay: with very big framerate, fractional values becomes too small, and rounding errors starts to accumulate. it may lead to various visual glitches, and sometimes to broken game logic. hence, FPS is capped. if you really want to get higher FPS, you can do "cl_cap_framerate 0" (this is boolean cvar). the cap will still be there, but the limit will be around 200.

 

or you can turn on VSYNC to get smoother rendering, and cap at refresh rate. ;-)

 

6 hours ago, 3t0 said:

So question is why is zdbsp needed, why bother with it? (due to mods?)

it is WAY faster than ajbsp. i.e. it is almost instant even on huge maps, where ajbsp can take several seconds to finish. but yeah, it mostly does things in the way that is suitable for GZDoom, sometimes taking shortcuts that plays nicely only with GZDoom renderer. but it is still freakin' fast, that's why it is default. i am not sure that it will be the default in the future, though. ;-) maybe i'll try to speedup ajbsp instead.

 

6 hours ago, 3t0 said:

Does it mean that "new" lightning model is still very unoptimized, or that is realistic cost it has?

both, as always. ;-) this is mostly due to huge overdraws, and overdraws are caused by renderer's inability to clip in 2D. as shadow volumes are pyramids, GPU touches alot of "pixels" for each one (stencil buffer has to be modified alot), and FPS tanks. recently i fixed some inefficiencies in clipper, bit it is still 1D, so improvements are small (yet sometimes noticeable). as you're building from git, you're already have those fixes.

 

this is one of the things i hope to fix with new renderer: it should clip geometry way better. but tbh, "stenciled" lighting is not my primary playing mode, i like lightmaps. dynamic lights in lightmapped mode now does shadows too (althrough it may be harder to notice than in stenciled mode). one can say that hard edges in "stenciled" lighting is more "doomish", tho -- as the engine cannot do smooth light transitions too. but i like lightmapped mode. ;-)

 

6 hours ago, 3t0 said:

Water handling is uber tragic!

and not only it! you can also stuck at sloped spike, for example (kdizd z1m1, yellow key -- run onto it, and BOOM! you're stuck there, impaled on spike ;-). i don't have time to revsit physics code yet. and thanks for your points, i'll put 'em in my internal TODO to investigate later. tnx!

 

6 hours ago, 3t0 said:

It all felt very quake-y, looked gorgeous, and unlike in Quake, I had great automap (which is also very tastefully done).

thank you! tbh, most of the work on the code was done by Janis (and Firebrand). and map authors, of course. but i am glad that you like it combined! ;-)

 

6 hours ago, 3t0 said:

Only problem I have with the wads is, that there is too few of them.

this is something i want to address too. i have some plans to implement in-engine tools for mappers, especially for doing lighting work. so people will be able to load map, fly into it, and add lighting with instant feedback. i think that this will help mappers alot, 'cause polishing lighing may be tedious af.

 

6 hours ago, 3t0 said:

So one of my nest questions is: would it be possible to have calculated lightmaps stored in lumps of map's wads itself? Currently it seems engine recalcs them each load.

the answer is "yes and no", as always. sure, loading prebacked lightmaps is not that hard (it will require some efforts, of course, and lightmap builder should be combined with nodes builder, and with sector subdivider, 'cause this is what the engine expects to be consistent; but this is not a huge problem).

 

the problem is that DooM levels are very dynamic by their nature: any sector can move up or down (and even change slope factor, althrough this is not currently used). this already gives some troubles with static lightmaps (like lamps not shining through open doors -- this is hardly noticeable, but it is there). i have plans to combine static and dynamic lightmaps into unified lighting system, where level changes will trigger proper lightmap recalculation (but it will be faster than naive lightmap regeneration), and dynamic lights became faster too.

 

now, if we'll have prebacked lightmaps, we can do radiocity tracing, but static lights should be really "static", i.e. placed in static level parts, away from lift and doors. this may or may not be a huge restriction, and i don't know if radiocity will make levels look much better. i will prolly implement this in the future just to see how it looks in real game, though.

 

 

thank you again for dedicating your time to write such big and detailed feedback! feel free to ask more questions if i missed something, or failed to explain. and stay with us, we have cookies lightmaps! ;-)

 

for now, i have no plans to drop k8vavoom: after all, this is my primary (and only) sourceport to play DooM. and i am playing (like, not engine playtesting, but "just playing") long DooM sessions at least once a week usually. so k8vavoom will prolly be maintained as long as i will keep interest in DooM itself. which wasn't faded in past 25 years, and i don't see any reasons for it to fade at least in next 25. ;-)

 

 

p.s.: and ROYAL "FUCK YOU!" goes to dw forum software, as usual. it took too long to write this response, and BOOM! you cannot submit it anymore, you have to reload a page first. and C-C/C-V lost all quotes. nice work, dw, thank you!

 

 

p.p.s.: oops. i forgot to tell about out-of-tree builds. they are... "kinda supported". the engine needs basepak.pk3 files built from "basev" contents, and put into proper places. your build works only by accident, and may break anytime. the expected way is to use "-DCMAKE_INSTALL_PREFIX=/any/path", and use "make && make install". most of the time the engine will find it's basedir when it is properly installed. and of course, you don't have to be root to install it: installing somewhere at "/home/user/vavoom" should work ok, and you will be able to simply run "/home/user/vavoom/bin/vavoom" (with optional "-iwad"; note that you can drop your iwads (or symlinks) to "~/.vavoom/iwads/", for example, and the engine will find 'em).

Edited February 10, 2019 by ketmar

[ketmar]

meh, "new save system build" is not ready yet again. i am thinking about turning it into running gag, it is ideal source: it is stupid, it is annoying, it is something nobody cares about. anyway, here is new build for ya:

 

* added some sanity checks to ACS, so `SetLineTexture()` won't segfault
* added ZDBSP as second internal node builder (it is way faster than AJBSP, and better for UDMF maps)
* added autodetection of number of CPU cores for PVS builder
* major clipper code cleanup (removed all copypasta)
* closed doors/raised lifts acts as clipping solid walls now
* added option to do better thing rendering, so things won't disappear when their containing subsector is not visible (this may slowdown rendering a little; or sometimes alot, so use with care!)
* activated ceiling floodfill fixhack
* menu UI fixes (titles, episode selection, etc.)
* removed some code from clipper (it should do less work, and clip more things without it ;-)
* `A_CheckProximity()` decorate action
* small fix for missile autoaim (player missile autoaiming should use missile z offset)
* fixed rare infinite recursion in sector movement code
* intermission: show "ALL" if level has no monsters/items/secrects
* play monster sight (alert) sound on dedicated channel, so it won't be interrupted by other monster sounds
* bots can be activated again (yet they are dumb af)

* don't save unchanged cvars to config
 

also, i changed some defaults. let's stop pretending that k8vavoom is vanilla-like. so i turned on gore mod, turned off autoaim for hitscan weapon, and turned on headshots.

[KVELLER]

18 hours ago, ketmar said:

also, i changed some defaults. let's stop pretending that k8vavoom is vanilla-like. so i turned on gore mod, turned off autoaim for hitscan weapon, and turned on headshots.

 

I imagine those things can still be reverted to their vanilla behaviour, right?

[ketmar]

22 minutes ago, KVELLER said:

I imagine those things can still be reverted to their vanilla behaviour, right?

sure, it is all configurable in "gameplay options". yet most people never looked in option menus if defaults are vanilla-like. therefore i changed some things, so people can either drop k8vavoom ("oh, option menus are too hard for me!"), or go explore what else we have in our pockets. ;-)

 

as for gore mod, it can be turned off with "-nogore" CLI arg. yet i don't know why somebody may want to do that -- after all, doom is all about blood and gore! ;-) and it is configurable too, from "some" to "bloodbath".

Edited February 16, 2019 by ketmar

[ketmar]

another random screenshot: it is now possible to have decals on translucent windows.

 

Spoiler

 

[ketmar]

and another thing nobody else can do (afaik): decals on "masked" textures. yeah, k8vavoom can properly render decal on a wall with "holed" texture!

 

Spoiler