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

k8vavoom: no good thing ever dies!

Recommended Posts

Having a good test with some wads and the performance of this is much more impressive than I was expecting! :) Had a run through my current WIP limit removing set and my old 2015 large limitless map with the stencil mode returning nearly constant 90fps at 4K on a Windows 10, Ryzen 1600, GTX 980ti machine. The lighting does a good job of subtly adding depth and mixes very well with the sector lighting. Would love to build some maps around this lighting! 


One bug I've noticed is decals are appearing on *scrolling textures. Another small bug/feature request; this port looks and feels great when pumping up the FOV, but going over the default 90 using the console makes the HUD weapon disappear so having a larger number like 110 but having the sprites in the normal HUD position would be great.

 

edit: scrolling textures, not animated textures

Edited by Khorus

Share this post


Link to post
40 minutes ago, Khorus said:

with the stencil mode returning nearly constant 90fps

your map is prolly not overloaded with much details. ;-) slowdowns are mostly from seeing alot of linedefs at once, level size matters much less. this, and my GPU is quite old too.

 

still, i have plans to make this even faster. i have plans to make everything faster, actually! ;-)

 

also, please, note that lightmapped renderer does proper light tracing too, with shadows and all that. it is harder to notice, 'cause lightmaps are more "smooth", but it is there. tbh, i like lightmapped light more than "hard-edged" stenciled light.

 

even dynamic lights in lightmapper renderer are traced. i had to add a heuristic to turn off tracing in some cases, tho, to avoid slowdowns. but i have plans (again!) to write a new lightmap caching system, which will allow me to remove hacks, and properly trace all dynamic lights.

 

40 minutes ago, Khorus said:

One bug I've noticed is decals are appearing on *scrolling textures.

yeah, they does. i found that fun, and thought about that as "there is invisible glass there, and now it is blood-stained". ;-) will prolly fix it anyway, it looks silly.

 

40 minutes ago, Khorus said:

so having a larger number like 110 but having the sprites in the normal HUD position would be great.

this is limitation of FOV implementation: it (and aspect ratio) actually changes projection matrices, and psprites are rendered out of place. that's why psprites are turned off on non-default FOVs. i will implement proper FBO scaling instead of changing projections later, and it will fix psprite rendering (and out-of-ratio statusbar too).

 

that is, your wish is noted, and will eventually became my command. ;-)

 

 

p.s.: actually, your FPS may be way greater than 90: this is hardcap in the engine. with the intermediate "mouse button test version" i published above, you can say "cl_cap_framerate 0" to see the real numbers. ;-)

 

 

p.p.s.: tried your map, and got ~25 FPS in the starting room with stenciled lighting. are you SURE that you actually turned it on? you have to restart the map after changing the renderer. your numbers looks like regular lightmapped renderer numbers to me. if you did it right, tho, you can see how much my GPU sux. ;-)

Share this post


Link to post

I remember trying GZDoom on Linux with my AMD Radeon RX 460 and Intel i5-6500, and the performance seemed to be lower.

 

Try replacing your GPU with a better one.

Share this post


Link to post
3 minutes ago, Cacodemon345 said:

Try replacing your GPU with a better one.

good suggestion. ;-) yet i barely have money to buy food, so getting new hardware is nigh to impossible for me.

Share this post


Link to post
3 hours ago, ketmar said:

good suggestion. ;-) yet i barely have money to buy food, so getting new hardware is nigh to impossible for me.

RIP

Share this post


Link to post

i bet you all eagerly waiting for something new. and you know what? we have it! a new build!

 

* added handling for more mouse buttons; it is not tested, so it may or may not work for you
* implemented some more flags in `A_FireBullets()` decorate action
* `A_StopSound()` decorate action now accepts optional argument
* made some arguments to `A_LookEx()` decorate action optional
* implemented "NotAutoAimed" decorate flag (actually, VaVoom had it properly implemented in VaVoom C all the time, but decorate got that flag after VaVoom EOL)
* implemented "$attenuation" in sndinfo (the engine had it, but parser didn't knew that)
* (partially) implemented `A_SetScale()` decorate action
* chainsaw sound won't stuck anymore (hope nothing else is broken)
* fixed node building bug with zero length segs in some UDMF maps
* `A_ReFire()` in decorate accepts optional argument (and it sometimes works)
* added `ACS_ExecuteWithResult()` decorate action (not properly tested yet)
* accepts more optional arguments for `A_JumpIfTargetInLOS()` decorate action
* better decorate parsing (some action names were searched as case-sensitive)
* no more decals on linedefs with scrolling textures (need better handling, tho)

Share this post


Link to post
5 hours ago, ketmar said:

i bet you all eagerly waiting for something new. and you know what? we have it! a new build!

 

* added handling for more mouse buttons; it is not tested, so it may or may not work for you
* implemented some more flags in `A_FireBullets()` decorate action
* `A_StopSound()` decorate action now accepts optional argument
* made some arguments to `A_LookEx()` decorate action optional
* implemented "NotAutoAimed" decorate flag (actually, VaVoom had it properly implemented in VaVoom C all the time, but decorate got that flag after VaVoom EOL)
* implemented "$attenuation" in sndinfo (the engine had it, but parser didn't knew that)
* (partially) implemented `A_SetScale()` decorate action
* chainsaw sound won't stuck anymore (hope nothing else is broken)
* fixed node building bug with zero length segs in some UDMF maps
* `A_ReFire()` in decorate accepts optional argument (and it sometimes works)
* added `ACS_ExecuteWithResult()` decorate action (not properly tested yet)
* accepts more optional arguments for `A_JumpIfTargetInLOS()` decorate action
* better decorate parsing (some action names were searched as case-sensitive)
* no more decals on linedefs with scrolling textures (need better handling, tho)

Any chance to have a switch update with those change? I know that the Switch port Is experimental but would be cool to try recent changes on the Switch port :)

Share this post


Link to post
6 hours ago, slash004 said:

Any chance to have a switch update with those change?

it is all up to fgsfds, my own work on switch port consists solely of: "yay, great (i mean, wtf is that switch at all?)!" he is working on a new build, and something more, afaik.

Share this post


Link to post

small (or big, dunno) news: after some work on decorate parser, bdlite can be loaded, and the game is even working for some time. before it shits itself all over the place and crashes, of course. i don't think that this will be ready for the next build, but this is at least something. i.e. limited support for user vars and scripting in decorate is on its way.

Edited by ketmar

Share this post


Link to post

hey, i forgot that i don't have a Real Release Plan, so i can upload new builds as often as i want! so, while i'll be working on some new big features, here's something for you to play with!

 

* `ACS_NamedExecuteWithResult()` and `CallACS()`
* added proper diagnostics for some unsupported decorate features (uservars and complex actions)
* better dehacked parser (both in standard and in bex format)
* rendering psprites on fov > 90
* some preliminary work on limited decorate scripting support
* decorate: more ACS API
* decorate actions `A_Lower()` and `A_Raise()` acccepts optional argument now
* fixed another bug in mapinfo parser (doomednum/spawnid sections were processed wrong)

Share this post


Link to post

teaser! bdlite running in today's k8VaVoom build! don't know why zombiemen are disappearing -- probably something with sprite naming.

 

don't get me wrong: i am absolutely not interested in supporting bdlite specifically. but it has some decorate scripting features, and it is nice thing to show (and it means that more mods will work too ;-). i.e. this is not something hacked in to support only bdlite.

also, please note that i am NOT planning to support full brutal doom: it is a fuckin' mess, i won't vandalize VaVoom code to support that shit. evar.

Edited by ketmar

Share this post


Link to post

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.

Edited by ketmar

Share this post


Link to post
2 hours ago, ketmar said:

teaser! bdlite running in today's k8VaVoom build! don't know why zombiemen are disappearing -- probably something with sprite naming.

 

don't get me wrong: i am absolutely not interested in supporting bdlite specifically. but it has some decorate scripting features, and it is nice thing to show (and it means that more mods will work too ;-). i.e. this is not something hacked in to support only bdlite.

also, please note that i am NOT planning to support full brutal doom: it is a fuckin' mess, i won't vandalize VaVoom code to support that shit. evar

Shit! I need an updated built for the Switch now!

Share this post


Link to post

it is too early -- almost nothing is working right yet. ;-)

 

besides, bdlite is fubared anyway -- sounds are broken, some sprites are broken, keys not working... and this is not k8VaVoom fault!

 

p.s.: but i found why zombiemen were disappearing. this is not a sprite issue, but a long-standing bug in state management, lol. hacked around it for now, and voila! zombiemen are at their respective places, aren't disappearing, and attacking me!

Share this post


Link to post

No problem, I may build it from the sources anyway. 

Btw any chance to support brightmaps? I know this isn't intented to be gzdoom but I think brightmaps shall fit perfectly with the current lighting/shadowing features from VaVoom :)

Share this post


Link to post

i myself not using brightmaps, and seen no brightmap pak that fits my tastes, so it is low on the list. i will prolly implement brightmap support in the (distant) future, but don't hold your breath. currently i am more interested in implementing dynamic light cache (so i will be able to get rid of precomputed lightmaps for "static dynamic lights"), and maybe implement shadowmapping ('cause stenciled lighting is way too slow on my GPU).

 

tl;dr: yep, i will eventually implement brightmaps. but don't expect 'em to be there soon. ;-)

Share this post


Link to post
3 hours ago, ketmar said:

currently i am more interested in implementing dynamic light cache (so i will be able to get rid of precomputed lightmaps for "static dynamic lights")

But precomputed lightmaps are great for crappy iGPUs like intel hd like I have :( At least I assume by "precomputed lightmaps" you mean baked lights correct?

Share this post


Link to post

yep, this is for lighting. and the engine is generating lightmaps for the lights it considers "unmoveable" at map loading time. then the engine does the very same thing for dynamic lights. lightmaps for "unmoveable" light sources is what i called "precomputed".

 

lightmap tracing is quite consuming (basically, you have to trace a line from light source to each lightmap texel), and it wasn't done for dynamic (moveable) lights in original VaVoom at all. i added that tracing (so now we have nice shadows from columns when fireball flies near, for example, and armor doesn't emit light thru secret walls), but sometimes it can consume alot of recources (when there are many dynamic lights visible).

 

it was a prelude. what i want to do instead is to leave this system, but remove concept of "unmoveable static light" at all. this "unmoveable" light is never recalculated, so it is wrong if nearby sector changes. i.e. i want to make ALL lights truly dynamic.

 

see, most of the time we can trace lightmap once, and reuse this info (and even lightmap) in next frames. currently the engine recalculates EVERY visible dynamic light on a new frame. drop many bottles around the complex structures like columns, add several flying fireballs to the picture -- and oops. my CPU drops to 20-30 FPS.

 

and i want to rewrite this system, so it will be both more dynamic, and more fast. reuse as much as possible from the previous frames, recalculate only if it is strictly necessary. basically, this is kinda like autodetection of unmoveable lights. in the previous example, lights from bonuses will be traced only once, instead on each frame. so the engine will have to re-trace only fireballs, instead of fireballs plus alot of bonuses.

 

 

tl;dr: i LOVE lightmapped light, it is soft and nice. i am not playing with stenciled lighting (it is almost unplayable on my GPU, lol -- <40 FPS on E1M1). and i want to make lightmapped light both faster (it will consume less CPU/GPU resources), and more "dynamic". owners of non-top GPUs and CPUs will only benefit from that, and will loose nothing. ;-)

Share this post


Link to post

@ketmar I felt like testing bdlite on the lastest build of k8vavoom (PC), but it says uservars aren't supported (this is know). What revision of bdlite are you using?

Share this post


Link to post

windows build doesn't have that implemented. the feature is not finished (not even stabilized), and it won't be in windows builds for some time.

Share this post


Link to post

Hello,  I always liked to tried Vavoom, but saw development stopped years ago.  Also, I use Xubuntu Linux for playing Doom, I tried searching in the posts of this  thead, but I didn't find if there is a precompiled *.deb installer... guess I have to compile it for Xubuntu? (Compiling from source is a nightmare in my case)

Share this post


Link to post

yep, GNU/Linux systems are DIY. i am not planning to create any kind of binary packages -- compiling the sources is The Right Way. it is not hard at all (easier than to find a matching pair of socks, actually ;-). once you'll stop worrying and love compiling, you will become rich and famous.

 

less schizo: i am unable to do binary GNU/Linux builds anyway -- my binaries just wouldn't work on your system. or on most other systems out there. you need either volunteer maintainers to build packages for your OS, or build from sources yourself. i recommend the later.

Edited by ketmar

Share this post


Link to post

@Danfun64 i implemented preliminary support for Chex Quest 3. it starts, you can walk around, shoot, and so on. dunno if it works right, though -- but looks ok. ;-)

Share this post


Link to post

almost last night in this lonesome october... and new build!

 

* hacked in support for decorate uservars
* limited enum parser in decorate
* more decorate actions (i am really tired of listing 'em each time, sorry)
* fixed bug with decorate branch commands (goto, etc.) -- they weren't working without empty TNT1 state
* "don't change frame" flag in decorate wasn't working (its meaning was inversed)
* optional HUD messages for saving/loading
* simulate "nodelay" decorate flag by inserting one dummy state
* implemented "canraise" decorate flag (untested)
* allow long sky names in "sky1" mapinfo commands (such name can represent gzsky)
* added experimental Chex Quest 3 support (use "-doom -chex -file chex3.wad" to start)
* implemented proper VaVoom C mods loading, so you don't have to copypaste the whole game VC code to replace one or two things (needed this for CQ3)
* autoloading .wads and pk3s from "basev/gamename/autoload/" directory (so "-nakedbase" CLI arg is more reliable now)
 

Share this post


Link to post
On 10/17/2018 at 8:20 AM, VGA said:

IMO if a port isn't a respectable and usable *Doom* port FIRST, there is not much community interest in it for any kind of modding. Look at Doomsday and EDGE, not much interest there and they always have technical problems and bad compatibility.

I think it was a problem of focus vs. competence. At some point, all of these ports shifted focus from "pretty powerful Doom engine" to "very powerful generic game engine." It's difficult to move all the hard-coded Doom stuff into scripts, and then back up and emulate all of Doom perfectly. This requires a sharp focus, and a dedication to compatibility... that may have become secondary to everything else.

 

@ketmar This is a very cool project! I love to see VaVoom getting some fresh love! Good luck with it! 

Share this post


Link to post

@ketmar BDLite runs nicely, isn't fully supported as you pointed before, bit IT'S something, so much potential on your VaVoom fork, and everything on my hand (Switch)!

Share this post


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