k8vavoom: no good thing ever dies!

[ketmar]

@kb1 tnx! actually, it is not that hard to maintain compatibility even with game logic moved to scripts (maybe even easier), but it is really hard to stop improving things once you got all the game code decoupled from the actual engine... ;-) still, for purists we have choco (and mocha), and prboom. it is really interesting to watch various directions people took with the engine. of course, VaVoom is the best sourceport on the planet, but i am always interested to see what others doing too. ;-)

 

@slash004 thanks! yet i should note that Janis put the great foundation: original VaVoom code is quite a pleasure to work with. i wonder what VaVoom could be today if Janis wouldn't stop development back then...

Edited October 30, 2018 by ketmar

[kb1]

15 hours ago, ketmar said:

@kb1 tnx! actually, it is not that hard to maintain compatibility even with game logic moved to scripts (maybe even easier), but it is really hard to stop improving things once you got all the game code decoupled from the actual engine... ;-) still, for purists we have choco (and mocha), and prboom. it is really interesting to watch various directions people took with the engine. of course, VaVoom is the best sourceport on the planet, but i am always interested to see what others doing too. ;-)

You're welcome! Actually, maintaining compatibility can be *very* hard, depending, again, on focus.

• The normal level of compatibility is in making sure that the IWADs play properly.
• The next stage is visual compatibility with all the vanilla and non-vanilla visual hacks, like the self-ref sectors, and high-level gameplay compatibility, meaning that all the linedefs work as expected, and things act as expected, under normal circumstances. This is a respectable goal, and many ports strive to maintain this level of compatibility.
• Finally, a port could focus on tic-per-tic, exact vanilla demo compatibility. This goal can dominate focus for a long time, and even after it is achieved. It's so easy to break vanilla demo compatibility, that the devs have to be extremely careful adding new features.

It's neat to hear about source code that's a pleasure to work with! Programmers don't get to say, or hear, that very often.

[ketmar]

oops. found a fun bug in acs thing spawn opcode. and fixed it. now Romero Death Skittles seems to be fully playable. at least i spent some time pla... er... testing it, and it seems to work fine.

[Aquila Chrysaetos]

On 10/27/2018 at 11:31 PM, ketmar said:

sorry, but i think i can't. i know nothing about Chex Quest, never owned it, never even seen it irl (youtube doesn't count ;-). i need volunteers' help to support Heretic/Hexen/Strife/Chex. i'd like to have them supported, but there is only so much i can do myself. alas.

 

ah, i see, CQ3 is a fan-made mod. dunno, it may work after i finish decorate scripting. or may not. it is hard to say yet.

Make sure you get the correct Chex 3. There's one on ModDB that is wrong. It has some bugs and other issues that have been fixed later on.

http://www.chucktropolis.com/gamers.htm

This is the link to the proper file.

[ketmar]

yeah, that is where i got it for testing. if running it for two minutes can be called "testing", of course. ;-)

[ketmar]

blood and lust light update! as people seems to use stenciled lighting mode, i finally found some motivation to fix decal rendering for you. and other changes:

 

* fixed translucend decals rendering for stenciled light mode
* fixed bug in ACS Thing_Projectile[2] spawner: we should reset gravity if it is turned off (text in Romero Death Skittles now properly flies up; tnx to id0 for spotting this)
* added more built-in decorate fields
* added language strings for Chex Quest
* added "-c" CLI arg to exit after compiling VaVoom C scripts
* don't crash on lines without front side (some maps has such strange linedefs -- let 'em glitch!)
* decals are properly lit by dynamic light in stenciled lighting mode

[ketmar]

by the way: you can set "r_light_filter_static_coeff" to 0.3 or 0.2 if your GPU is fast enough. k8VaVoom "filters" static lights in stenciled light mode by removing lights that are too close to each other. if you have two torches near a narrow hallway entry, for example, one of them can be filtered out. by chaning this cvar (and restarting map/reloading save) you can control filtering. the lesser value is, the closer lights should be to each other to be filtered out.

[slash004]

Thanks for the update @ketmar!

[ketmar]

put some fun bonus for ya all: Spelunky Classic remake, done with k8VaVoom technology! ;-) this is standalone VaVoom C runner, k8VaVoom sound system, and OpenGL API. enough to write a decent platform game, you see. i.e. the whole game is done with VaVoom C, including loading assets from internal format (binary file parsers with VaVoom C, yay!), and per-pixel collision detection. if you're interested, "game.dat" is just a zip archive.

 

have fun, and happy spelunking! ;-)

[Danfun64]

So where's the spelpub source code?

[ketmar]

vcc runner is inside k8VaVoom source repository, Spelunky source code is inside "game.dat".

[ketmar]

next update will feature some user-invisible, but important changes: new save format (with names and typeinfo, so changes to internal objects will not automatically invalidate old saves), and moving many menus to textual definition files (so future mods will be able to extend/add menus without resorting to VaVoom C code). but nope, menudef format is not compatible with GZDoom. ;-)

[Gunrock]

Hey everyone!! Just logged in after being away for more than two years to find out someone finally resurrected Vavoom!! It was the best source port IMO and I made a few mods with it (Silent Steel Adamantium, Dark Wispers, and Braham Manor). I tried out ketmar's fork and it was amazing work!!!! I have a few questions to ask:

 

1. Are you planning to have a dedicated web site to show off your amazing work to a bigger audience in the doom community?

2. Any plans for a launcher (similiar to Doomsday, Gzdoom, etc) that can load custom mods, high res textures, etc)?

3. Does the engine still support Quake style static lighting?

4. How much of Decorate support are you implementing?

Sorry for all the questions, I have been away from the doom community for well over two years.

[VGA]

8 minutes ago, Gunrock said:

Hey everyone!! Just logged in after being away for more than two years to find out someone finally resurrected Vavoom!! It was the best source port IMO and I made a few mods with it (Silent Steel Adamantium, Dark Wispers, and Braham Manor). I tried out ketmar's fork and it was amazing work!!!! I have a few questions to ask:

 

1. Are you planning to have a dedicated web site to show off your amazing work to a bigger audience in the doom community?

2. Any plans for a launcher (similiar to Doomsday, Gzdoom, etc) that can load custom mods, high res textures, etc)?

3. Does the engine still support Quake style static lighting?

4. How much of Decorate support are you implementing?

Sorry for all the questions, I have been away from the doom community for well over two years.

Do your mods work with the new version?

[ketmar]

8 hours ago, Gunrock said:

I tried out ketmar's fork and it was amazing work

thank you!

 

8 hours ago, Gunrock said:

1. Are you planning to have a dedicated web site to show off your amazing work to a bigger audience in the doom community?

nope, only this thread. alas, my financial situation... you can read the first post to know more. ;-)

 

8 hours ago, Gunrock said:

2. Any plans for a launcher (similiar to Doomsday, Gzdoom, etc) that can load custom mods, high res textures, etc)?

i believe that it is better to support something like ZDL than to create Yet Another Launcher. at least not until there is a high demand for one. ;-) i myself don't need any lanucher at all (i have a set of shell scripts to do all the work), so it is low in my list. alas, there is only so much time i can dedicate to k8VaVoom -- i have to sleep sometimes! ;-)

 

8 hours ago, Gunrock said:

3. Does the engine still support Quake style static lighting?

sure! both stenciled and lightmapped renderers are there, and even better than before! lightmapped renderer now has shadows for moving lights, and bonuses won't shine through secret walls (most of the time, at least ;-). i only removed pre-shader OpenGL1.x rendering path (it was broken anyway, didn't had all the features of shader renderers, and i see no reason to support it).

we also have decal support. technically engine can support decals on floors too (it doesn't matter for the code if we'll put decal on a floor or on a wall), but i didn't implemented any way to define those. maybe later.

 

8 hours ago, Gunrock said:

4. How much of Decorate support are you implementing?

eventually almost everything that was there before zscript introduction will be implemented. we already have uservar support (no arrays yet), and partial anonymous function support. there is no real roadmap here, though -- i am just implementing things i need (or things people asking for, and i see it as fun ;-). zscript will not be supported, of course.

 

8 hours ago, Gunrock said:

Sorry for all the questions, I have been away from the doom community for well over two years.

no problems, you're welcome! as i don't have real presentation for the sourceport, questions are inevitable. and i'm happy to answer.

 

 

8 hours ago, VGA said:

Do your mods work with the new version?

at least Braham Manor is working perfectly. basically, anything that doesn't do VaVoom C scripting will work. and it was quite hard to do modding with VC in the original VaVoom: the only way to do that was to create a TC. this is something i am working on too -- it is already possible to load custom VC code from mods without forking the whole game code.

 

and any VaVoom total conversion can be ported to k8VaVoom quite easily -- it is mostly a matter of adding `override` keyword here and there. yet i don't know if anybody except Korax RPG did such TC.

 

p.s.: for Braham Manor you only need to pass all files to k8VaVoom, there is no need to create new base directory. it seems that originally it was done to separate saves (and to ease loaing), but k8VaVoom is smart enough to do it by itself. and it is able to load .pk3 from zip archive without unpacking that archive.

 

p.p.s.: ah, i remember Dark Whispers. it works too. and i just checked Silent Steel -- it seems to run flawlessly too.

Edited November 4, 2018 by ketmar

[ketmar]

if you're all interested: Silent Steel Adamantium. to play it, extract .zip, cd into "Silent", and run k8VaVoom with "-doom2 -file *.pk3" there (if your shell supports wildcard expansion). it is better to use lightmapped renderer with this mod. go try it, it is fun!

 

p.s.: saving may be broken in the current k8VaVoom build. sorry. new build will be uploaded soon.

 

@Gunrock SSA is fuckin' great! i remember playing it years ago, and i had alot of fun. now i am replaying it, and it is still as fun as it was. thank you!

[Gunrock]

Thank you!!! I'm really motivated into getting back to mapping for K8Vavoom.

[slash004]

@ketmar while I agree you shouldn't break your mind in supporting every mod that has GZDoom in mind, you should at least support some popular mods such Smooth Doom, BDLite and perhaps Beauty Doom, perhaps some modders may consider to mod for k8vavoom in a future, in fact, I alreally tweaked some existing gzdoom's mods to work under k8vavoom :)

[ketmar]

27 minutes ago, Gunrock said:

I'm really motivated into getting back to mapping for K8Vavoom.

that would be great! my best mapping effort is "two rectangles connected with another rectangle", so i cannot produce anything to show off [k8]VaVoom engine features. and your maps are k00l, with all that lighting work and such. also, we're close to full-featured modding with VaVoom C too, so you can drop ACS and use the full power of VC to script your creations! (and i am always here to implement features you may want). there is no proper documentation for VC scripting, though (i started brief VC description, yet it is far from complete), but i am here again to answer questions. ;-)

 

i also have long-term plans for new rendering code (don't worry, both lighting modes will still be there -- it just should be faster and better), and some plans for in-game editing (so you will be able to place things and lights in the game itself -- i believe that it will help people to do better lighting with less efforts). dunno, maybe it will be even possible to include basic geometry editor too.

 

 

16 minutes ago, slash004 said:

you should at least support some popular mods such Smooth Doom, BDLite and perhaps Beauty Doom

sooner or later the engine will be able to do that. ;-) yet bdlite is shit-broken by itself ('cause brutal doom is a pile of shit, not 'cause bdlite author is incompetent -- quite the contrary, he did a great work cleaning up sargeant's crap). GZDoom is way more forgiveable with decorate shitcode. for example, k8VaVoom insists on proper argument typing for decorate actions (and i found some bugs in several mods due to this). and insane things like `A_Jump()` with 72 arguments (72! that's nuts!) will not be supported ever (not because i can't do it, i don't want to do it) -- so winter's fury will not work, for example.

 

there is also alot of unsupported ACS opcodes too. they are too many to implement 'em without proper testing, so i am implementing only those i see in some mod i want to play.

 

yet i fully understand that mods are what keeping DooM scene alive. that's why almost each build comes with some decorate improvements (sometimes user-invisible, but they're still there ;-). it is just decorate is such a mess that it is hard to implement everything people are using, and i only have 24 hours per day to do everything (including sleeping). ;-)

 

still, i am taking notes of what people want to run with k8VaVoom, and it has some influence on my development decisions. like "bump that feature from 386 place in TODO list to 327". ;-)

[slash004]

I completly understand, in fact, one of the mods I tweaked to work under k8vavoom was Particle Enhanced Fire Effects, which had a fuction with +50 arguments, just wiped out that shit and viola, it worked :) I may look into BDLite to be fully featured under k8vavoom along with others mods (eriguns is other mod I would love to see working under k8vavoom).

On the other side, I didn't know with things like Brutal Doom were to much demanding considering that it is still DooM (heck, even it still uses vanilla sprites instead of full 3D models and that shit lags on my laptop), hope modders can see that there are other interesting modern sourceports than gzdoom in the horizon, and I will be honest here, the only reason why I did keep an eye on k8vavoom is why it was the choice of fgsfds for the Switch, in fact, I only use the PC version of k8vavoom for testing, I mainly use the Switch port, but indeed I can see the big potential that k8vavoom has, shadowing is enough for k8vavoom to be praised :)

[ketmar]

30 minutes ago, slash004 said:

the only reason why I did keep an eye on k8vavoom is why it was the choice of fgsfds for the Switch

i know. and this is good enough reason for me -- way better than "i don't care". ;-)

 

btw, preliminary support for SmoothDoom is almost there. you will prolly be able to try SmoothDoom in the next build.

[ketmar]

dammit. as smoothdoom requies that, we now have support for cvarinfo, and limited support for gzdoom-style menudef. i HAET chasing the leader instead of setting my own rules, but... ;-)

 

p.s.: both things are done completely on VaVoom C side. that is for you to know how flexible and powerful k8VaVoom engine is. ;-)

[ketmar]

little teaser to fuel your dreams. ;-) this is from unmodified SmoothDoom.pk3.

[Cacodemon345]

The UI looks much, much more better than GZDoom.

[ketmar]

heh. both mine and GZDoom UI sux. ;-) i only hope that mine sux little less. but let's be honest: we both failed our UX design homework. ;-)

 

fun fact: i have quite full-featured flexbox layouter in VaVoom C. it means that technically i can build declarative UI of any complexity, with automatic layouting. of course, it is not used anywhere, and we only have this boring menu system.

[TheMightyHeracross]

I'm surprised no one's talking about that very impressive Spelunky mod. That's completely unrecognizable as a Doom engine game... I just wish there was more documentation on VavoomC so I could understand the source code.

 

I feel like that's likely to be a big issue in getting people to mod for Vavoom. VavoomC doesn't have an equivalent to, say, the ZDoom wiki and its extensive coverage of DECORATE, ACS, ZScript, etc.

[ketmar]

1 minute ago, TheMightyHeracross said:

Spelunky mod. That's completely unrecognizable as a Doom engine game...

ah, it is not a doom engine game. it is using parts of k8VaVoom technology, bit it cannot be run in k8VaVoom engine itself.

 

it is possible to make it work as k8VaVoom mod, though: it only using standard 2d texture blitters, which is absolutely doable with k8VaVoom (the whole UI system is built from those parts). one day i'll convert it into "real mod", just to show off how powerful the full engine is. ;-)

 

that is, you can think of Spelunky as "dumbed down k8VaVoom engine", with all 3D features taken off. heh, i am planning to implement in-game editing tools, with windowed UI -- that will show people what we really can do! ;-)

 

7 minutes ago, TheMightyHeracross said:

VavoomC doesn't have an equivalent to, say, the ZDoom wiki and its extensive coverage of DECORATE, ACS, ZScript, etc.

yeah, lack of documentation is a huge issue. i only hope that if i will continue improving k8VaVoom, someday we'll get somebody to help with that. and if not... well, it can't be worse than now anyway. ;-)

[Gunrock]

Hey ketmar, just wondering how much work would it take to implement this mod

 

 

[ketmar]

@Gunrock alot.

first, implement md3 support. doable, and in my TODO list (yet it is not a small task -- i need to basically rewrite the whole model rendering code).

second, implement gzdoom modeldef. doable, absolutely not in my todo list.

otherwise -- i just made another decorate fix, and it works. yet it is very hard to play without graphics. ;-)

 

p.s.: i'll look later if it will be possible to write a conversion tool to translate gzdoom modeldef to vavoom's models.txt.

 

little explanation: i will implement gzdoom definitions support only if it is possible to do in pure VaVoom C. currently models cannot be defined from VC (lack of design and API, mostly), so no support to modeldef.

 

in the future i will try to move almost everything (map loaders, other parsers, etc. -- except decorate parser, of course ;-) to VC side. the more things i will move to VC, the more gzdoom misfeatures we'll be able to support. like cvarinfo and menudef, for example -- they're done completely in VC, no C++ engine changes were made.

Edited November 6, 2018 by ketmar

[slash004]

Just tried SmoothDoom on k8vavoom on the Switch and it looks fenomenal! I also tried BDLite to see improvements and looks like it is broken (got a crash trying to load it), perhaps due to unfinished code but I guess that once fixed, *may* be fully working on k8vavoom (just like under gzdoom), who knows ¯\_(ツ)_/¯

Edit. I can provide a log if you wish