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

Fair enough, thank you for your candor.

I wish you the best of luck in your endeavors!

I'd probably do so in a heartbeat if we had some decent multiplayer stuff going on from the get-go.

Fully 3D polyobjects are certainly nice, for sure.

Quick question... can you use VavoomC to change how it reads sprite names?  Like, you can change the index name to be up to 8 characters + frame letter(s) + rotation index/indices, instead of 4 characters + frame letter(s) + rotation index/indices?

Let me make a comment. But vavoom is a new engine, as the name of the site www.vavoomengine.com/ suggests. But on the other hand, it is focused on doom, as follows from the motto: "The first unified doom engine source port".
For a universal 2.5D game engine, like cube 1, you need to fork k8vavoom, and for this need a team of developers.

Personally, I see a lot of potential in multiplayer. Similar to the Assault Cube, but with free resources (to get to libregamewiki.org/List_of_games ). Besides the fact that the assault cube resources are not free, the cube engine also lacks something in the gameplay that idtech1 has.

lol, I also have problems with English and Google translated my neutral text "need to fork k8vavoom" into a guide to action "you need to fork k8vavoom". There's a completely unnecessary "you".

Not everyone knows Russian. Google has a harder translating Russian than English. I need to formulate the Russian sentence correctly from the very beginning so that Google can translate it more or less clearly. And then I look to see if he added extra words to my words.

Не все знают русский язык. Google переводит русский язык сложнее, чем английский. Мне нужно с самого начала правильно сформулировать русское предложение, чтобы Google смог его более-менее понятно перевести. А потом смотрю, не добавил ли он к моим словам лишних слов.

the problem is that one have to know not only about networking, but the engine internals too. netcode is very tightly coupled with engine data structures, and even with the engine design. tbh, this is the hardest problem in finding a helping hand: before writing (or fixing) something more-or-less complex, you may spend monthes, or even years trying to untangle the logic. i literally spent years learning how the whole beast (Vavoom) worked (and there are still parts i don't fully understand ;-). and i must admit that Vavoom code is one of the cleanest codebases i've seen, yet it still took a lot of time. and if you'll start diving into k8v internals, you'll hardly have any time or energy left for doing something else. ;-)


yep, k8vavoom can do this. i mean, it already works like this, players are connecting to the spawned server at any time, without server or other clients waiting for the full party before start playing.

the engine is really redesigned to be client/server (you may read "spawning server with map XXX" in console when starting a new map; and it is not a cheap trick, this is what really happens ;-). internally, the code is separated too, sfx like particles are done in client code, for example. if you'll look into game basepaks, you will find "progs/game" and "progs/cgame" dirs. this is server and client support code respectively.


the problem is that in texture manager, texture name IS its index. and some code builds or checks sprite names dynamically, expecting them to be in Doom format. and then sometimes assign this built name as "current frame". that is, the engine passes around `VName`, which represents internalised string index. it also expects that each `VName` can be exploded back to string, and you can aseemble new name from a string at any time. supporting UDMF feature where you can specify the full path to the texture was already a PITA (and a gross and dirty hack). and in object states, current animation frame is kept as `VName` as sprite base, plus frame number. then the engine builds a full texture name out of this (sometimes using simply `char buf[8]` as buffer ;-), and using it to find a proper texture in texture manager. also, as names are texture indicies, there is no way to have two different textures with the same name. sadly, such code is scattered across the whole engine.

so while replacing sprite names in DECORATE with something else could be done easily, everything still have to adhere to Doom base4+frame1+rotation scheme, and should be unique.


yeah. and a way for mods to avoid sprite conflicts will be nice too. still, the most realistic way to achieve this is to allow each actor specify a full path to sprite data, while still sticking with 4+1+rot scheme (as you suggested above).


p.s.: i should tell you a little secret, though. most of the time when i'm telling that something is impossible, and dumping walls of text explaining why exactly it is impossible, it really means that i am already thinking how to make it possible. ;-) i can't promise anything here, of course, but maybe i'll eventually find a way to hack around sprite name restriction. this will definitlely be a dirty hack… but hey, idTech1 is just a collection of hacks anyway! ;-)

yet the problem is not only in sprite code, but in texture manager too. and in sprite texture scanner (the engine builds a list of all known sprite textures on startup). tbh, now the problem looks slightly more interesting than it was… ;-)

the framerate is deliberately capped at around 70, see `cl_framerate` cvar (this is hard limit, the actual framerate can be slightly lower — that's what you see). you can change it, but there is a little reason to go beyond 60. while it may look smoother on 120Hz displays and such, the engine will start to slowly fall apart, because it is not a lock-step one. the smaller frame time delta is, the worser everything goes.

at 120 FPS it should be still playable, albeit somewhat unstable (physics and such). the hard cap is 250, any higher values will be capped to this. but i'd recommend to stay with vsynced 60. feel free to change `cl_framerate`, but you're on your own with that. ;-)

just in case other people are interested (and because i love to write text walls), i explain why high FPS is a problem for k8vavoom. other sourceports are lock-step engines: internally they are locked at 35 FPS, no matter what. with higher FPS they simply interpolate positions between two "real" game frames, but it doesn't affect gameplay at all.

but k8vavoom advances the game state exactly by the time delta between two frames. it is not "locked" to particular framerate internally. while this gives nice effects like smooth motion of lifts and physics for free (because they're moving exactly the required amount, no interpolation needed), there is one big problem here: small deltas. as deltas became smaller and smaller, various floating point values accumulate more and more errors.

in lockstep engine delta is always the same, so all values are always predictable and stable. but in "lock-free" engines delta is varying, and with small delta some values may simply refuse to update at all (their update may become too small after various calculations). which may lead to various glitches — not only visual, but actual gameplay glitches.

60 FPS is ok. 120 FPS is probably ok. 240 FPS may work, but we're entering dangerous zone here. something arount 500 FPS will prolly start glitching. 1000 FPS will glitch hard.

so i set default cap to 70 to stay on the safe side. besides, 70 is a refresh rate of most displays when Doom was released (hence its internal 35 FPS clock). i may later bump the default cap to 140, but i don't think that i'll go beyond that.

i believe that 140 should be safe enough to play without problems, though, so if you have a 120Hz display and want game framerate to match it, change that cvar. i didn't bumped it mostly because i didn't tested the engine enough in that mode. please, note that it is better to set framerate limit to something slightly higher than display refresh rate, and rely on vsync. 130-140 is a good value for 120Hz refresh rate.

reworked Vavoom C mod loader code; introduced new VC mod description format
Interesting. What's this exactly? Related to loadvcs/loadvcc?

cosmetic fix (nobody uses pk3 anymore anyway)
Lmao

EDIT: Something more important. I can't seem to compile with Fluidsynth at the moment.
[ 13%] Building C object libs/fluidsynth_lite/src/CMakeFiles/libfluidsynth_lite.dir/utils/fluid_settings.c.o
/home/tdrr/Programs/k8vavoom/libs/fluidsynth_lite/src/utils/fluid_settings.c: In function ‘fluid_settings_setnum’:
/home/tdrr/Programs/k8vavoom/libs/fluidsynth_lite/src/utils/fluid_settings.c:1067:30: error: declaration of ‘setting’ shadows a previous local [-Werror=shadow=compatible-local]

we're simply talking about different levels here. ;-)

you're mostly talking about definition, and i am talking about implementation.

in the implementation, models are completely separate from everything other. nowhere in the engine (except the low-level renderer, of course) nothing knows about model existance at all. basically, the renderer simply "intercepts" sprite drawing calls, and replaces sprites with models.

but actor frame is the whole different story. we cannot simply replace sprite frame image at the very last moment, because the engine also uses actor frames to check for various things, including (but not limited to) image translucency, for example. and it does this assuming that frame name always corresponds to the texture, avoid passing the actor pointer around. (at least that is what i remember about the code; the beast is HUGE. ;-) the engine also using frame names to batch actors, so it can use less render calls; there is experimental (not commited) code for dynamic actor texture atlases (which is partially done in BSP traversal), and so on. this will break horribly if i try to replace frame images somewhere along the way.


that was exactly what i thought about: in DECORATE, you can set base texture path for each actor, and the engine will read textures from there, not from SPRITES subdir. yes, frame names will stay the same, but frame images will be different. and that is THE problem: we need 1:1 correspondence between frame name and frame image.

on startup, for example, the engine scans all available sprite frames to build various tables (rotations, etc.). at this stage, no actors are loaded yet, so the scanner doesn't know about frame overrides. and even if it will know that, rotation info may be wrong due to conflicts (override has more than 8 rotations defined, but base textures defines only 8, for exampe). and rotation table is global for all actors (we need it to be that way).

there are other places where the engine doesn't except sprite frame images to suddenly change too.

so it's not only about substituring one texture with another on rendering (which works for models). properly implementing such feature will require several major redesigns of various engine parts. that's why this proposal was rejected in GZDoom, for example: they faced the same set of problems.

so i have to think hard about new designs for this feature. because i don't want to sacrifice engine performance (and it heavily depends on some immutable info pregenerated on startup), and don't want to turn the code into unmaintainable mess too.

yeah. it is to allow to have mod description in one file, like this:
"vavoomc_mods.rc":

server {
 options {
   skipbdw
 }

 pre {
   k8zan_server
 }
}


client {
 k8zan_client
}


that is done to avoid problems with future additions. now i can extend the thing without ugly hacks, and without fear of breaking something.


i almost decided to declare any GCC higher than 6 as unsupported. ;-) my GCC6 is silent about that, so i commited a blind fix. let's hope it will work. thank you!