Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
ketmar

k8vavoom: no good thing ever dies!

Recommended Posts

i still want to write a new renderer. i will prolly go into (almost) radio silence mode soon, and will try to implement my renderer ideas.

 

otherwise, everything will go as usual: i'll continue implementing missing decorate and ACSF features, so we'll have more and more things working.

 

tbh, i have a quite long private TODO list, but i won't speak about it in public, 'cause people will expect it to be implemented, and i want to have some room to maneuver. ;-)

Share this post


Link to post

more teaser pictures! ;-) this time it is SkullDash. HUD is done with k8VaVoom-specific VC mod, loaded after skulldash pk3.

 

Spoiler

shot0032.png.9fb33a1cb9af40562aeaa4bd23a518e0.png

 

Share this post


Link to post

i don't think so. nothing personal, i just see it unfit for that place. and i certainly don't want to maintain two threads on forums with broken (or non-existing) email notifications. i'd rather spent that time improving the engine.

 

as i side note: i wanted to upload a build today, but when i got out of bed, i found open code editor with some unfinished mess i wrote before falling asleep. so i'll finish another small feature for new changelog (it is big this time) before new build will be ready. ;-)

Edited by ketmar

Share this post


Link to post

i feel like this build will never be "ready enough", so... you're in for surprise, you're in for a shock! this build will rock!

 

* SAVES ARE BROKEN! (i know, i know... sorry... i am trying to do my best, really)
* implemented more ACSF opcodes (mostly PickActor and activator change family)
* some ACSF bugfixes (mostly in dynamic string handling)
* fixed very nasty ACS VM bug (how did it worked at all with garbled locals?!)
* fixed disappearing HUD messages when message ends with color code
* weapon replacement actors now properly occupies slots of replaced weapons
* set weapon fire mode before changing weapon state, so first state action will get correct fire mode
* implemented decorate uservar access opcodes in ACS
* all decorate uservar access is properly checked now, so the engine will not trash random memory on bugs
* fixed prev/next weapon switching
* properly mark objects for garbage collecting, so stale monsters/HUD messages will not stay in object list forever
* fixed state resolving, so jumps to "name.subname" states in decorate should work better
* `A_WeaponReady()` now allows you to fire in primary mode if secondary mode is disabled ;-)
* alot of other decorate fixes, and some new decorate actions
* "Activation" property support for switchable decorations (not yet complete)
* fixed loading of ACSe files without actual script code
* fixed alot of places where velocity can become nan/inf (and then origin, and then... oops)
* workaround for stupid mods with option menu override in MENUDEF
* proper decal offset, including decal things (hi, LWM, it was a smart trick!)
* optimized garbage collector, so excessive amount of actors are processed way faster now
* implemented (very hacky!) crouching, so skulldash tutorial level can be completed without cheats (it is a cheat, 'cause it doesn't change max player speed)
* -file can mount directory as emulated pk3 (useful for developers, so they don't have to constantly repack their mods)
* some more loading progressbars (which you prolly will not see if your PC is not as old as mine)
* fixed ACS control button processing (buttons should not be updated more that once per DooM frame)
* fixed "+nointeraction" decorate flag (such actors should become "ephemeral")
* it is now possible to use decorations (sometimes)
* fixed nasty bug in ACS direct opcodes with string args (they were all wrong)
 

(sidenote: hdoom is mostly working. don't ask me why.)

 

p.s.: HUD mod for SkullDash EE. load after SkullDash EE.

skulldashhud.zip

Edited by ketmar : typo in SkullDash spelling

Share this post


Link to post

Congrats on the new build.

 

10 minutes ago, ketmar said:

(sidenote: hdoom is mostly working. don't ask me why.)

Hmmmm

Share this post


Link to post

fun fact: hdoom code is one of the best mod sources i have ever seen. good code design, very competent programming, sane use of inheritance, comments in obscure actions, ZERO warnings on loading, detecting sourceport features and utilizing them. THAT is how mods should be done!

Share this post


Link to post
2 hours ago, ketmar said:

fun fact: hdoom code is one of the best mod sources i have ever seen. good code design, very competent programming, sane use of inheritance, comments in obscure actions, ZERO warnings on loading, detecting sourceport features and utilizing them. THAT is how mods should be done!

 

Who would've thought that, of all mods, HDoom would be one of the better coded ones, heh.

Share this post


Link to post

yeah. tbh, i expected it to be a mess of at least brutal doom scale. and found something i can advice to learn from instead. the author even included all ACS source code in it. no, really, mod creators should study hdoom to learn good practices!

Share this post


Link to post

VERY LONG developer rant follows. you can skip it if you aren't in the mood to read mostly useless technobabble.
 

Spoiler

what i really HAET is when people not only using acs `delay()` to do hard time syncing, but also rely on script execution order. skulldash, for example, does the later: one its script clears all HUD messages, and second shows new message. woe to player if second script is called first. i understand that there was no other way to do time syncing, and not blaming people for doing it, but still...

now, why am i talking about that at all, you may ask. to answer this, we should take a look at how videogames are working internally. of course, it is quite the same thing in general: get user input, run logic for all game objects, draw new frame, repeat. the devil is in detils, as always.

doom (and many other games) are using so-called "lock-steping". it allocates ~28.5 milliseconds per frame, and won't start next frame until this time expired. this gives us 35 frames per second, which was ok for its time.

but for modern machines we can do much better. like, if we'll bump FPS to 60, we'll get nice smooth movement. but we cannot just make doom tick each ~16.66 milliseconds: the game will become almost twice as fast! while many people love "fast mosters mode", this is not the right way to implement it. ;-) and just rendering the same frame twice wont give us anything, of course. we need to interpolate entity movement between frames.

now, we have two possible solutions to this problem. first, leave the game logic intact (i.e. run it at constant speed internally), and interpolate movements instead. i.e. remember entity positions from a previous frame, and smoothly move entities to their new positions as time passing (i.e. if we'll rendering twice as much frames as the original, we can move entities half the way for the first frame, and do second half for the next frame). this is how it is done in most (if not all) doom sourceports today (and that is what all those "interpolate" flags in decorate are for).

but there is another way to do the same thing: we can change game logic to be able to work with different "delta times". i.e. all actors knows how much time passed since last frame, and can do only part of required work. i.e. if actor has to move by 6 map units per second, for example, and it got "delta time" of 0.5 seconds, it should move only by 3 map units. this is almost the same as interpolation, but instead of remembering last actor position and do it in-engine, we simply changed game logic code to do it for us "for free". now we can call game logic as often as we like to, and we aren't depend of frame rate anymore. at all. this is "free step" mode, and this is how VaVoom does it.

of course, switching to free step mode introduces slight timing deviations to the expected engine behavior. while the original engine state was perfectly predictable. i.e. if you know engine state at a given moment in time, and all RNG seeds (let's assume that player is not doing anything), you can calculate the exact position, speed, etc. of everything in doom world at any point in the future. this is how vanilla doom demos are done: the game just recording user input, and then run "world simulation" starting with exact same state as it was when demo was recorded. as everything is fully deterministic, each demo replay will be the same. this is also how networing works in vanilla -- only player movement is sent to peers. this is also the source of demo/network desyncs.

with free step move, different machines can run the simulation at different time steps (and even on the same machine there will be slight deviations in frame times due to other running tasks). this is not a problem for game logic code (it will adapt itself), but game state is not quite predictable anymore. this is where we should know another thing about computers: computers are notoriously bad at remembering numbers!

yeah, computers are working with numbers. but there are different kind of numbers. for our purposes, we're interested in integral and fractional numbers. while working with integral numbers is easy, working with fractional numbers is much harder. most of the time computer remembers not the exact fractional number you gave it, but something "close enough" to it. i.e. when you wrote "0.5", computer may remember it as "0.49999999999". it is almost the same, but not the same. now imagine that this is our "delta time" between frames. and actor should move by 10 units per frame. with exact numbers, it will move by exactly 5 units (10*0.5). but in rality, it will move by 4.9999... units. repeat this enough time, and the error will accumulate.

now, this is not a real problem for videogame. the videogame is quite random by nature, so players won't notice such slight deviations (and when we need exact movement -- like with lifts, we just checking if lift height is greater or equal to required height, and if it is, we're forcing lift to be at required height).

ok, if you remember where it all started, you probably starting to understand why stepping time matters for scripts. yeah, in VaVoom acs script delays can deviate slightly, due to fractional arithmetic inexactness. this is not a problem per se: execution order is still intact, the engine takes care of that. but if script shows HUD message that should last for 2 seconds, and then call `delay()` 60 times, and then replaces HUD message with another... oops. thanks to error accumulation, script won't run in the exact moment it wants to be run. this can lead to "HUD flickering". it is not a game breaker, but sometimes it is still annoying.

and there is almost nothing i can do with it -- each solution will inevitably break something. like, trying to round delay times by 28.5 msecs caused script desync in skulldash, so some messages were never appearing. but hdoom visual novel mode were working perfectly. and without force-rounding skulldash is perfect, but hdoom's vn portraits flickers.

that is, free step mode is nice, and simplifies VaVoom alot (also gives us free interpolation and some other nice things), but sometimes it is hard to maintain full 1:1 compatibility with vanilla. and contrary to what you may think, i wrote this post to advertise VaVoom's free step mode. and to explain why correctly emulating some vanilla things may be harder in VaVoom than in most other engines. but i am still glad that Janis took that way, i like it.

 

Share this post


Link to post

so far, we have most of ACSF opcodes implemented, and many decorate actions either implemented at least partially, or got missing features. it is good. now it's time to recover some damage i done at early stages of engine development (i didn't fully understood what is going on there at that time, and wanted some things to "just work"), and improve other things. like: i accidentally damaged texture manager -- it works, and it works better than before, but the code is a mess. renderer seems to do some unnecessary work sometimes, and fail to render some ROR structures properly (and this is not me ;-). and networking... there is a great foundation, but it is not polished.

 

so, i will prolly start to work on those features now. it means that new builds won't be released often, 'cause not all changes can be done incrementally, and there is little to really show you -- it is hard to show "better code" with binary files. ;-)

 

as git master is used to create AUR packages, the developement of major features will mostly be done in private branches, so don't worry if git will get no updates for a long time. some of changes are very experimental by their nature, and final result may be scrapped if it won't show the improvements i wanted.

 

i will occasionally post here to keep the topic alive. and will upload new builds with more ACSF/decorate/fixes, of course. so don't turn off your tvs, our show is far from finished.

Share this post


Link to post

and some small news: Strife is runnable now. dunno if everything is working right, but at least you can walk, you can talk with NPCs, you can get quests. tnx to @Khorus for help.

Share this post


Link to post

tbh, i am not sure that pbr is suitable for doom aesthetics. but i will not say "won't do it", 'cause each time i am saying something like that, i found myself busy implementing the exact feature i refused to implement. ;-)

 

anyway, new renderer i am planning should be faster than the existing one. this is the primary goal of rewriting: i know that i can make it faster without sacrificing features. and maybe with cleaner code. ;-)

 

thank you for you interest in k8VaVoom (for whatever reason ;-).

Share this post


Link to post
10 minutes ago, ketmar said:

tbh, i am not sure that pbr is suitable for doom aesthetics. but i will not say "won't do it", 'cause each time i am saying something like that, i found myself busy implementing the exact feature i refused to implement. ;-)

 

anyway, new renderer i am planning should be faster than the existing one. this is the primary goal of rewriting: i know that i can make it faster without sacrificing features. and maybe with cleaner code. ;-)

 

thank you for you interest in k8VaVoom (for whatever reason ;-).

Depends on what do you mean with "suitable for doom aesthetics", if you mean vanilla aesthetics there are chocolate doom and its forks which alreally provides that experience. Remember back in the day when I tried OG VaVoom and was quite impresive how well shadowing was done and imagined what could be VaVoom in the future in terms of features and fancy graphical fx, after all, OG VaVoom aimed to be the most advanced DooM sourceport, probably VaVoom could be way more advanced in features then GZDoom if Janis did continued with his work today. But then you are here reviving VaVoom as your own fork called k8VaVoom :)

Share this post


Link to post

it is just i am not a big fan of hires textures, or mods, or other things like that. for me, "most advanced" means internal architecture and code, not graphical features. i prolly will never try to compete with GZDoom on gfx "battlefield" -- i just don't see enough value in that. i mean, we already have GZDoom for those who wants advanced graphics, and GZDoom does it well.

 

sure, if people will start making levels specifically for k8VaVoom, there might be a reason to add pbr, so levels will look spectacular with VaVoom lighting. but this is kind of chicken-and-egg problem: i won't work on pbr before people will start making levels, and people won't make "pbr-ready" levels until i add pbr. ;-) and by the time i may implement that feature, there will be "gzdoom standard on pbr". and i really don't want to restrict myself with what GZDoom did. i am not saying that they're doing it wrong, i just don't want to copycatting their design, i want to do my own.

 

so pbr in k8VaVoom is possible, but... i don't know when or how they'll appear. ;-)

Share this post


Link to post
39 minutes ago, ketmar said:

, so levels will look spectacular with VaVoom lighting.

Exactly my point, VaVoom's lighting is superior compared to other sourceports plus it has shadowing, something that other sourceports does not feature, so PBR would fit perfectly on VaVoom's engine IMO.

Share this post


Link to post
21 minutes ago, slash004 said:

something that other sourceports does not feature

you're not quite right: GZDoom has shadowmapping for more than year now (maybe several years, i don't really remember). it is a different technology, but it looks like VaVoom lightmapping. i don't remember if GZDoom is capable of properly clipping dynamic lights, tho (so that powerups won't shine through secret walls). it prolly can.

Share this post


Link to post
3 minutes ago, ketmar said:

you're not quite right: GZDoom has shadowmapping for more than year now (maybe several years, i don't really remember). it is a different technology, but it looks like VaVoom lightmapping. i don't remember if GZDoom is capable of properly clipping dynamic lights, tho (so that powerups won't shine through secret walls). it prolly can.

 

GZDoom's shadowmaps work perfectly, but only as long as the zone that is blocking lighting is "empty" (i.e. isn't a sector), so if the powerup is in front of a door, it will shine right through.

Share this post


Link to post

@KVELLER that was VaVoom problem too (in lightmapped mode). 10 y.o. CPUs weren't powerful enough to properly trace dynamic lights (and all light tracing is done on CPU side), so Janis choose to not do it. as we have much powerful computers these days, i just added tracing to dynamic lights (and some heuristic to not trace 'em on open places), so now powerups won't shine. but that was a consequence of how lighting was done in VaVoom: dynamic lights aren't that different from static ones in the engine -- the same code is used to build both static and dynamic lightmaps, so it was only a matter of adding "traceline" call to dynamic part.

 

with GZDoom, it is harder, 'cause shadowing is done as a separate step. they will need to trace each dynamic light, sampling alot of points to check if it can span to other areas. or make some heuristics to detect secret walls (it is doable too). still, it is not a matter of adding two lines of code. i think they will fix it eventually, though. ;-)

 

p.s.: GZDoom does shadowmapping completely on GPU side (it even uploads a simplified BSP tree to GPU to trace light there), and it is quite expensive to modify GPU data when sector moves. that is prolly why they still have those "shine-troughs", 'cause their shadowmap code is capable of clipping with door/secret wall geometry.

Share this post


Link to post

small update. not a long changelog this time. i am mostly uploading this so you can lay your hands on Strife and tell me if there is something REALLY wrong with it.

 

* even faster GC (not that you will notice it, but ludicrum+gore got another 0.5 FPS)
* more decorate actions and fixes (no, i am really tired to write 'em all here, even if it makes changelog very long and impressive)
* more ACS ACSF opcodes (see comment above ;-)
* if thing was moved by boom sector transporter, it should slide along walls
* fixes to crouch mode (correct attack height, correct viewheight after falling/jumping, walk/run speed limits when crouching)
* preliminary support for Strife is back! (tnx, Khorus!)

Share this post


Link to post

I am probably a noob for asking this but how do I load strife1.wad.

Creating a shortcut with Target "vavoom.exe" -iwad strife1.wad isn't working. Heretic and Hexen work fine this way.

Share this post


Link to post

ah. please, don't do it that way. the official way is to specify "-game <name>" cli arg. or just "-name". like:

vavoom -doom2

vavoom -nerve

vavoom -strife

your wads should be where vavoom can find them (you can use "-iwaddir" to specify iwad directory). by not specifying correct game you may skip some important initialization steps, and the game may be glitchy, or not working at all.

 

the engine tries to autodetect a game from iwad, but that code is very rudimentary, and mostly tested with doom/doom2 wads. and even in those cases it is unreliable. so please, help vavoom with cli args. ;-)

 

p.s.: note that you can specify multiple directories with "-iwaddir", like "-iwaddir <dir1> <dir2> <dir3>", and vavoom will try to find iwad in each directory.

Share this post


Link to post
35 minutes ago, ketmar said:

vavoom -strife

 

I now did this and Strife is still not loading(Heretic and Hexen load fine). Strife (Strife1.wad) is placed inside the iwad directory so i shouldn't need to specify with -iwaddir

Share this post


Link to post

are you sure that you updated everything? i checked strife specifically before uploading, and it worked fine.

 

AAAAH! i found it! you need "voices.wad" too. i somehow missed "optional" flag there, so without voices strife won't run. sorry. i'll upload fixed build tomorrow.

Share this post


Link to post

@ReaperAA for now, you can workaround that by editing "share/basev/games.txt". just remove "addfile voices.wad" in Strife definition, and it will work.

Share this post


Link to post
11 hours ago, ketmar said:

@ReaperAA for now, you can workaround that by editing "share/basev/games.txt". just remove "addfile voices.wad" in Strife definition, and it will work.

 

It starts now. Thanks

(Though ingame HUD is bugged so its not really playable yet)

Share this post


Link to post

@ketmar

I appreciate your discussion about free step mode - that is a very interesting concept, and I think I understand your issues with scripts that delay(60). I haven't studied the code at all. I am assuming that your script interprets "delay(60)" by setting a counter variable to 60, then the game loop iterates the scripts, with something like:

 

script.counter -= (current_time - last_time);

if (script.counter <=0)
  run_script;

Is that basically what's happening? If so, it seems like you might fix the timing issues as follows:

 

  • Create a global gametime_ms which is set to current_time * 1000;
  • When Delay(60) is parsed, instead of storing script.counter = 60, store script.counter = ( current_time + (60) ) * 1000 + script_number;  (strange, I know)
  • Parse through the scripts, calculating:
int i;
int first_script = -1;
int first_delta = INT_MAX;

for (i=0; i < script_count; i++)
{
  script[i].delta = gametime_ms - script[i].counter;

  if (script[i].delta >=0 && first_delta > script[i].delta)
  {
    first_delta = script[i].delta;
    first_script = i;
  }
}

if (first_script != -1)
  run_script first_script; 

Or, you may have to sort the scripts on .delta, to be able to run more than one. This change does a couple of good things:

  • Frame #2's delta against Frame #1 is constant for everything in the new frame, so calculating it once makes sense.
  • I've switched a countdown timer with an alarm, if that makes sense. This calculation is also only done once (minimal roundoff error)
  • Adding script_number to this alarm only adds milliseconds, but it imposes an exact sequence upon the scripts, forcing script 1 to run first, then script 2, etc. It's a bit of a hack - a multiple-field sort is probably a cleaner looking way to do it.
  • The * 1000 minimizes the impact of adding script_number to the script alarm time.

 

Please note that my loop above only finds the first script to run, so instead of using the "first_" variables, it's better to sort the scripts by delta, for each script where script.delta >=0, and run all of them in sorted order. This should solve the roundoff error if the scripts are written in the proper order in the WAD. If not, it will still work for most scripts, except those where that exact timing and order of operations is needed. But, regardless, it will fail the same way consistently. This type of change should be very efficient, and require minimal changes. The idea is to avoid float1 += float2 in the script timings, or to force all scripts to rely on a single global instance of float1 += float2, so all scripts see the same delta each frame.

 

Just a thought - hope it helps. I think this is a very cool project, and I love to see VaVoom getting maintained! Great job!

 

Edited by kb1

Share this post


Link to post

tnx, @kb1. so you suggesting to implement lockstep-emulation mode for scripts, and if more than one script is going to execute, then execute them in the order they were executed last time (with a smart trick that stores execution time in delay counter). yeah, i thought about that (and even half-implemented that solution), but tbh, i don't like it. not that there is something wrong, but it feels so hacky and dirty, that i just don't want that into the engine.

 

besides, that really helps only a little. all other things are still not "lock-stepped", and while timing issues becomes more... "predictable", in reality it glitches even more. like, HUD messages are not lock-stepped too, for example. so scripts will still miss the timing (many, if not most scripts are creating "fadeout" HUD messages, and just replacing 'em in the very last game tick). so next step will be locking of HUD. while it is not a hard task too, i foresee that next i will find another small thing i'd better lock. and then next one. and... and this is all for want of a nail.

 

thank you for suggesting the idea, though. it is always nice to know that solution you invented is something other people thought about too -- it means that you're not crazy. or at least that other people are crazy like you. ;-) yet for this case i think i'll stay with slightly flickering HUD UI (after all, creating user UI with ACS HUD messages is a gross hack by itself! ;-), and with simplier engine code. meh. after all, The Right Way to create UIs in k8VaVoom is VaVoom C. i know that in the future the world will forget about all other sourceports anyway, i just have to wait a little. ;-)

 

 

p.s.: just to clarify: most problems are with scripts that does `delay(1)` 60 times, for example. this is where error accumulates. "locking" script delays to game ticks solves that, but due to fairly random delta times, HUD updates still missing the target.

Share this post


Link to post

also, uploading a "strife-fixed" binary has to wait for some more days. sorry. but it wasn't a hard promise! ;-)

 

i accidentally (lol) moved weapon slot info from global level variable to player pawn instances (so different player classes can have different weapon arrangement), but now some weapon switching code has to be rewritten. i don't think that you would like to play with broken weapon switching! ;-)

 

and some good news: by commenting one line of code, i managed to reduce RAM consumption for decorate-heavy mods by a factor between 5 or 7. yep, you got it right: before, complex doom+lca were barely fitting into 3 GB of RAM, and now they need only ~500 MB. considering that windows builds are 32 bit, this matters alot. also, this should make some huge difference for Switch port too.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×