k8vavoom: no good thing ever dies!

[ketmar]

i implemented UMAPINFO support (will give it finishing touches when we'll clarify the specs). i guess i should create VMAPINFO too, because no sourceport can be considered mature without it's own mapinfo definition file, slightly incompatible with all other mapinfos out there.

 

p.s.: nope, DMAPINFO will not be supported.

[ketmar]

also, i am working on t-junction fixer for the next build. t-junctions are those nasty running white dots you can ocasionally see on some walls. rooms with 3d floors may still have some occasional dots, but otherwise you should see much less of those (none, i hope). the exception is floors and ceilings in lightmapped renderer: to properly draw lightmaps, the engine must subdivide flat surfaces even more, creating more t-junctions on its way. and it is quite hard to fix. it is doable, but i need to redesign some internal renderer structures to do that, so it will prolly wait for some time. sorry. but i'll eventually fix lightmap renderer too.

 

tl;dr: stenciled and shadowmapped renderers should be mostly free of white dots with the next build. at least this is The Plan.

Edited January 24, 2021 by ketmar

[Remilia Scarlet]

I don't think anyone even uses it anymore, but just in case you weren't aware... The standalone glvis doesn't want to compile anymore.  Z_exit() isn't found by the linker.  Changing to _exit() fixed it for me.
 

9 hours ago, ketmar said:

DMAPINFO

But what about Doomsday's version? :-P  Actually I haven't even heard of DMAPINFO before.

[Gez]

21 minutes ago, Remilia Scarlet said:

Actually I haven't even heard of DMAPINFO before.

It's the variant created by sponge for the official re-release port. It's encountered in the Official Add-Ons™ and that's about it.

[ketmar]

4 hours ago, Remilia Scarlet said:

I don't think anyone even uses it anymore, but just in case you weren't aware... The standalone glvis doesn't want to compile anymore.

ah, i just forgot to throw it away. it does nothing useful anyway (and it never even worked right). i will prolly remove it, and all remnants of PVS code in the engine. it would be much better to implement unreal-like realtime occlusion clipper instead.

 

4 hours ago, Remilia Scarlet said:

But what about Doomsday's version? :-P

snowball in hell, i guess. ;-)

 

p.s.: and i did removed all PVS code. it wasn't active for years anyway.

Edited January 24, 2021 by ketmar

[Remilia Scarlet]

On 1/24/2021 at 8:33 AM, ketmar said:

ah, i just forgot to throw it away. it does nothing useful anyway (and it never even worked right). i will prolly remove it, and all remnants of PVS code in the engine. it would be much better to implement unreal-like realtime occlusion clipper instead.

I saved a copy ^_^;;;

Also, with the latest commit (d36d71f17c9b104692327050a5fd5f87fae02c7c), when loading a savegame (normal or quickload), I get this happening to my psprite:

Spoiler

Gave me a good laugh XD  It goes back to normal once I switch weapons, though.

Edited January 26, 2021 by Remilia Scarlet

[ketmar]

4 hours ago, Remilia Scarlet said:

Also, with the latest commit (d36d71f17c9b104692327050a5fd5f87fae02c7c), when loading a savegame (normal or quickload), I get this happening to my psprite:

yeah, this is due to internal changes to psprite view state management code. when the engine saves objects, it doesn't simply dump the data, but stores class name, field name, field type, etc. i.e. alot of info to reconstruct save in case class layout changes (that's why savegames aren't broken with each new build ;-). it also tolerates missing or extra fields (extras are just ignored, missing fields set to default values). in this case, i moved general psprite offsets out of viewstate array, and internally normal Y offset is not zero. but i forgot to set the proper default value for it. it is absolutely harmless, and only affects psprite rendering, tho. and looks fun too. ;-)

 

p.s.: about glvis -- be VERY careful with it. it is numerically unstable (wild guess, i don't know the real reason), and may easily get into endless loop, calculating PVS for eternity. this was one of the main reasons i removed it: it doesn't worth any repair efforts, the engine does much better job even with its current dynamic culling anyway.

Edited January 26, 2021 by ketmar

[Remilia Scarlet]

Will do!  I'm mainly experimenting with it right now with my CL-DoomView and my own Doom port.

Yeah the psprites went back to normal once I made a new savegame.  Probably isn't worth fixing, it was just humorous and unexpected.

[ketmar]

19 minutes ago, Remilia Scarlet said:

Will do!  I'm mainly experimenting with it right now with my CL-DoomView and my own Doom port.

i'd recommend to switch to beam clipper, as other engines do. most of the time it can do better work in realtime than PVS after hours of precalcing. ;-)

 

the basic idea is that you have 1D array (actually, a list), which holds obscured angle ranges (i.e. "the area from this angle to this angle was already used, there's no reason to render anything there"). as you're doing BSP rendering (it is guaranteed to be correct front-to-back), you add each rendered segment (this is important: not line, but segment) to clipper, marking angles between seg vertices as "culled". of course, before actually rendering anything, you check if any part of the new seg is visible. there is also a simple and fast way to check this for 2d bounding box, so you can throw away whole subtrees, if no BSP bounding box part could be visible.

 

internally, clipper simply a list with ranges (from, to). on adding, you can merge ranges if necessary.

 

this doesn't work good for windows, tho (because the clipper is 1D), but you can improve things later, adding various checks, like "can midtex be visible" (if not, the seg can be considered "solid"). also, don't forget to check for sector heights: zero height is a closed door, so its segs can be considered solid too.

Edited January 26, 2021 by ketmar

[ketmar]

so, "white dot fixing" seems to work for advrender (stencil/shadowmaps). sadly, lightmapped renderer is as bad as it was before, due to subdivisions. it needs a completely different approach, much more complex and much slower. i'm not sure how to implement it yet, sorry. it will be fixed, but it will need more time for design and testing. anyway, "white dots problem" was there literally for decades, so have it solved at least partially is better than nothing, i guess. ;-)

 

just in case: don't worry, lightmapped renderer won't be declared "obsolete" or "deprecated"; it has its own charm, and i am absolutely commited to keep it.

[ketmar]

updated SDL2, and added very barebone "controller support". only buttons and dpad are supported (and i don't know if they will work at all ;-), no controller hotplug, no analog sticks. sorry, i don't have any hardware to test it, so i implemented only the part that looks like something that has a chance to work without testing. i prolly won't even put it into changelog, so if you're not watching this thread closely... then it's good for you, i guess, to not be disappointed.

[Mr.Rocket]

I have an 8 button controller that I use mainly for fighting games or M.A.M.E arcade shooters.

Mouse and kb is strictly for Doom games etc however "for me", I'll try it out and let you know if it worked for me or not.

~ well when the binary's available.. :P

Edited January 28, 2021 by Mr.Rocket

[ketmar]

thanks! i myself not really need any controller support (as you may guess ;-), but there are people who prefer/like to play Doom with a controller, so why not? after all, for Doom controller is roughly like a keyboard, you usually don't need alot of looking up/down anyway. i wanted to add controller support for a long time, but it's hard to do without a hardware (i don't even know for sure what value for analog stick is "down" ;-). my friend has a controller (dunno which), but i keep forgetting to take it for testing. ;-)

[Mr.Rocket]

Oh totally agree, even though I'm not one to use a controller for a 3d shooter, others would prefer it, and there's never anything wrong with more options. ;)

[furyweb]

Does K8vavoom have a max FPS, I cant seem to go above 65fps with or without VSYNC.

[ketmar]

first, don't forget to select "set resolution" after changing vsync option, otherwise it has no effect. second, it may be due to your GPU -- stenciled lighting and shadowmaps are quite demanding (yep, your GPU may run modern FPSes at decent frame rates, but struggle with k8vavoom rendering; this is due to Doom being generally hostile to such things). there is a default cap too, it is around 90 FPS.

Edited January 28, 2021 by ketmar

[ketmar]

p.s.: if you want to know why there is FPS cap -- this is mostly because Vavoom is freestep engine. all other (afaik) Doom sourceports out there are "lockstep" -- i.e. they run playsim at fixed rate (35 times per second), and interpolate. Vavoom (and k8vavoom) doesn't do that, it runs playsim by the actual time (much like Quake and Unreal), only interpolating some fixed actor movement. i.e. if your FPS is 90, (k8)Vavoom runs playsim in 1/90 steps. the higher FPS is, the smaller the step, and the higher the risk of floating point rounding/inexactness to manifest themselves. that's why there is soft cap at 90 FPS (which can be turned off in the console), and hard cap at 200 FPS (which cannot be turned off). i prolly should raise soft cap to 120, tho.

 

fun side-effect: type "dbg_frametime 0.004" in the console, and enjoy Max Payne-like "bullet time". ;-)

Edited January 28, 2021 by ketmar

[ketmar]

just a random pic to bump the thread. ;-)

Zan from Hedon in Eternal Doom world. and Grate Shadowing.

 

Spoiler

 

[YeOldeFellerNoob]

Just thought about this. You should make a Tech Demo showcasing mostly the new lighting systems, and much more added to this source port.

[ketmar]

7 hours ago, ✯𝔉𝔢𝔩𝔩𝔬𝔴𝔑𝔬𝔬𝔟✯ said:

Just thought about this. You should make a Tech Demo showcasing mostly the new lighting systems, and much more added to this source port.

yeah. but there are some problems. first, most lighting designed to "just work" with existing maps, the main idea is that you don't have to do something special. and second, i cannot create a map to save my life. i mean, to show off the lighting, we need an impressive artistic map, and i can't even properly texture two rectangles.

 

also, missing documentation helps too. ;-)

 

tl;dr: i can't imagine, nor create something interesting to show off k8vavoom power. let's hope some mapper will come to save me. ;-) also, there are Gunrock maps (Silent Steel:RE and others), they're fun to play and looks great. and, basically, most ZDoom maps with dynamic lighting.

[wallabra]

What is the Git repository address? Is it that weird Czech provider? Can I fork it into GitHub?

[ketmar]

13 minutes ago, Gustavo6046 said:

What is the Git repository address?

just a free git hosting. based in some university and sponsored by some entities, afair, but they never tried to monetize it in any way.

 

14 minutes ago, Gustavo6046 said:

Can I fork it into GitHub?

you can do anything allowed by GPLv3. ;-) as for something like "one-click fork" or something -- i don't know, because i am not using github, and it wasn't interesting for me. it should be supported on the github side, i think, not on repo.or.cz.

[wallabra]

Yeah, I could import it. Thanks!

[ketmar]

5 minutes ago, Gustavo6046 said:

Yeah, I could import it. Thanks!

good luck! i bet you'll need it if you really want to read the code. ;-)

[Remilia Scarlet]

Hey, I noticed that sometimes I can fit through gaps that I shouldn't be able to fit through.  Doom 2 map 22 was where I first noticed it, but another place off the top of my head is Plutonia map9 also suffers (you can get just the blue or yellow key and fit through the gap).  This is where I noticed it in Doom 2 map22.  All I have to do is walk up to a gap in the bars and look left/right a bit while walking forward and I can get through.  So yeah, I can totally break a few levels like this :-P

I checked in Chocolate Doom, Doom Retro, and Doomsday.  They all seem to block the movement, so I'm guessing that's the correct behavior.

Edited February 7, 2021 by Remilia Scarlet

[boris]

1 hour ago, Remilia Scarlet said:

Hey, I noticed that sometimes I can fit through gaps that I shouldn't be able to fit through.  Doom 2 map 22 was where I first noticed it, but another place off the top of my head is Plutonia map9 also suffers (you can get just the blue or yellow key and fit through the gap).  This is where I noticed it in Doom 2 map22.  All I have to do is walk up to a gap in the bars and look left/right a bit while walking forward and I can get through.  So yeah, I can totally break a few levels like this :-P

I checked in Chocolate Doom, Doom Retro, and Doomsday.  They all seem to block the movement, so I'm guessing that's the correct behavior.

 

It is possible in other ports. The distance between the bars is 32 units. It (and probably other guided glides, too?) just seems to be way more easy to pull off in k8vavoom .

[wallabra]

On 2/5/2021 at 5:28 PM, ketmar said:

good luck! i bet you'll need it if you really want to read the code. ;-)

 

I mean into GitHub, but yeah I can read your weird class stuff.

[ketmar]

On 2/7/2021 at 11:19 AM, Remilia Scarlet said:

I checked in Chocolate Doom, Doom Retro, and Doomsday.  They all seem to block the movement, so I'm guessing that's the correct behavior.

as @boris said, it is still possible even in vanilla, just much harder. Vavoom is not a lockstep engine, so with high framerate it is much easier to fit the player there (due to much smaller movement steps). having gaps of exactly 32 units (for default player) is exploitable map bug. it just happened that the exploit is much easier to... well, exploit in Vavoom due to its unique internal architecture. ;-)

 

tl;dr: not a bug, and i'm not sure if i have to fix it (and i don't even know how to do it without fully ditching original coldet code). DoomWiki has the article about that. that's "bar glide" trick. some other glide tricks are much harder or totally impossible in k8vavoom, tho, because the engine splits any fast movement to smaller steps, and i changed sliding code to use proper box tracing for the upcoming build (which means that you won't stuck in a walls as often as in other sourceports; damn, i'm good!)

 

p.s.: i may increase player radius a little (by 0.5, for example), so it won't fit anymore. it shouldn't be noticeable. dunno, maybe i'll add this as Yet Another Useless Option.

Edited February 9, 2021 by ketmar

[Mr.Rocket]

Here's something that might relate to that. In Dwango5 map01 where the BFG is and normally even in vanilla you can pickup the BFG through the gated wall texture.

Most ports allow this too, but some do not. 

[ketmar]

@Mr.Rocket this is Grab bug. yeah, Doom coldet works by utilising "microteleports", i.e. the player first moved to the new position, then the engine checks if that position is not occupied by any walls (and gets all pickups too, because `TryMove()` always collects pickups), and if the position is occupied, the player is returned to the previous position, and the engine calculates sliding. so in vanilla you can grab some items behind walls. in k8vavoom it is possible too, but again, it is much harder to do on higher framerates.