k8vavoom: no good thing ever dies!

[ketmar]

7 minutes ago, seed said:

Wait what, there's more renderers?

 

Where??

if you don't see them, than i have a bad news for you. ;-) the engine allows to select another renderers if your GPU is capable of supporting them. so if you have only lightmapped one (right there, "level renderer" in video options), then your GPU is too weak to support other available renderers. then it may be very possible that it can only do 65 FPS.

 

p.s.: which is very strange, considering that your GPU is way better than mine. ;-)

Edited February 14, 2021 by ketmar

[seed]

1 minute ago, ketmar said:

if you don't see them, than i have a bad news for you. ;-) the engine allows to select another renderers if your GPU is capable of supporting them. so if you have only lightmapped one (right there, "level renderer" in video options), then your GPU is too weak to support other available renderers. then it may be very possible that it can only do 65 FPS.

 

I doubt that.

 

But I don't know where to look either. "Where is it?"

[Mr.Rocket]

Video Options>Renderer>Level Renderer

Edited February 14, 2021 by Mr.Rocket

[seed]

13 minutes ago, Mr.Rocket said:

Video Options>Renderer>Level Renderer

 

Thanks, will check tomorrow.

[ketmar]

8 minutes ago, seed said:

Thanks, will check tomorrow.

also, i lied. default framecap is 70, not 90. so 65 is perfectly fine number here, considering that windows timer has lower resolution than i need to maintain a perfect framerate. ;-) this is "sv_framerate" cvar.

 

p.s.: but you'd better don't touch "sv_" cvars at all. if you want to get uncapped framerate, use "cl_cap_framerate 0". but expect all kinds of weirdness on high framerates -- the cap is there for a reason.

Edited February 14, 2021 by ketmar

[seed]

5 minutes ago, ketmar said:

also, i lied. default framecap is 70, not 90. so 65 is perfectly fine number here, considering that windows timer has lower resolution than i need to maintain a perfect framerate. ;-) this is "sv_framerate" cvar.

 

p.s.: but you'd better don't touch "sv_" cvars at all. if you want to get uncapped framerate, use "cl_cap_framerate 0". but expect all kinds of weirdness on high framerates -- the cap is there for a reason.

 

"You filthy liar."

 

Heh, no, I see, that may explain why it always stays at 65 too, never goes above that. And in that case, Adaptive left alone truly does nothing. That's fair.

 

So two issues left then, mouse turning speed with VSync, and its odd frame skipping.

[ketmar]

@seed also, i bumped default client framecap to 140 for the next build. let's hope nothing will break. ;-)

[seed]

7 minutes ago, ketmar said:

@seed also, i bumped default client framecap to 140 for the next build. let's hope nothing will break. ;-)

 

What's this, modern games to have physics tied to framerate 😉?

 

I guess the worst that can happen is some effects playing too fast or breaking in funny ways, but nothing else. Maybe?

[ketmar]

12 minutes ago, seed said:

What's this, modern games to have physics tied to framerate 😉?

 

I guess the worst that can happen is some effects playing too fast or breaking in funny ways, but nothing else. Maybe?

Vavoom (and k8vavoom) is unique among Doom sourceports, because it is not a lockstep engine. i.e. it doesn't run playsim on internal 35 FPS, and then simply interpolate, it honestly advances the playsim by the very amount of time passed from the previous frame. this usually is not a big deal, but with very high framerates time delta may become too small, and calculated velocities and such may become even smaller, introducing physics bugs due to floating point inexactness/rounding.

 

so you're partially right: k8vavoom physics is somewhat framerate-dependent. ;-) it should be safe at least up to 250 FPS, but i never really tested it (my GPU cannot go above 110 even on the starting area of MAP01 anyway). and if physics go mad, everything will break horribly -- lifts, monster movement, coldet, missiles...

Edited February 14, 2021 by ketmar

[seed]

3 minutes ago, ketmar said:

Vavoom (and k8vavoom) is unique among Doom sourceports, because it is not a lockstep engine. i.e. it doesn't run playsim on internal 35 FPS, and then simply interpolate, it honestly advances the playsim by the very amount of time passed from the previous frame. this usually is not a big deal, but with very high framerates time delta may become too small, and calculated velocities and such may become even smaller, introducing physics bugs due to floating point inexactness.

 

so you're partially right: k8vavoom physics is somewhat framerate-dependent. ;-) it should be safe at least up to 250 FPS, but i never really tested it (my GPU cannot go above 110 even on the starting area of MAP01 anyway). and if physics go mad, everything will break horribly -- lifts, monster movement, coldet, missiles...

 

Just like the good days, but it's interesting to hear this.

 

Still, I don't see why anyone would want such high frames in Doom, but who am I kidding, there always are such people who just care for the numbers. The current default cap is just enough for me, no real need to go above 60.

[ketmar]

12 minutes ago, seed said:

no real need to go above 60

it may be desirable for people with 120Hz-refresh displays. and i added 20 frames "just in case". i just thought that sooner or later somebody will ask why their fancy new 120Hz dpy cannot show more than 60 frames, so i may raise the cap right now, and try to catch some bugs in advance.

Edited February 14, 2021 by ketmar

[ketmar]

heartbeat notice. new build is near. just before releasing it, i decided to rework BSP tree, switching back to 2d bounding boxes for nodes. now the renderer and some other code is slightly broken. good news: implemented some fixes for Boom transparent doors and windows: now in most (all 3 i tested) cases they should render right, and with doortracks/windowtracks (previously, there was nothing at the sides). the example is translucent windows in Community Chest 2 MAP19. also, big boring changelog, as usual.

 

p.s.: if somebody's interested why 3d bboxes for essentially 2d map... it was for the idea i dropped later. so 3d bbox update code (quite complex) was simply wasting CPU cycles for nothing.

Edited February 23, 2021 by ketmar

[ketmar]

ahem. removing 3D BSP bounding boxes was a smart idea. god bless "git revert". i completely forgot that i need them to perform proper frustum culling in renderer (so, for example, looking vertically down won't try to render the whole 360-degree view). and some ketmar forgot to properly comment that.

[Remilia Scarlet]

Bah, who needs frustum culling.  Draw everything, every frame.  Twice, even, just to be sure. [/joke]

Anyway, is there something sorta like the "stats" command in GZDoom that will show me some rendering debug info?  I'm trying to figure out why a level I'm working on is slowing down in a particular area without enabling/disabling things repeatedly in the menus (if it's even a rendering setting).

[ketmar]

9 hours ago, Remilia Scarlet said:

Anyway, is there something sorta like the "stats" command in GZDoom that will show me some rendering debug info?

sadly, we don't have that yet. i am planning to implement full-featured profiling subsystem, but this task is so boring, that i'm moving it further and further away. ;-)

 

there is a small trick, tho: you can use "dbg_autoclear_automap 1" console command to clear automap on each frame, and then watch which parts of the map are rendered. as the clipper is 1D (1.23D ;-), you may find that some window or some gate actually doesn't block anything, and renderer does alot of work.

 

also, sector skies/stacked sectors may be slow. looking straight up to the sky in open area is slow (i'm working on it).

 

and you can use "?" in menu to print option cvar, and create aliases too. there is "toggle <cvarname>" console command to toggle boolean cvars, and you can use "bind" to bind aliases to keys.

 

better in-engine tools for mappers is something i'm planning to implement for a long time, and i even have parts of the supporting framework ready, but... 24 hours is not enough. ;-)

[ketmar]

10 hours ago, Remilia Scarlet said:

Bah, who needs frustum culling.  Draw everything, every frame.  Twice, even, just to be sure.

heh. shadowvolume/shadowmap renderer actually renders the scene 3+ times. ;-) ambient pass, texturing pass, fog pass, and various parts of the scene for lighting.

[Murdoch]

On 12/4/2020 at 3:40 PM, Remilia Scarlet said:

I dunno, I was just playing some Doom 2 with it and found it fun as hell XD  Nicely playable framerate, too.  Most of my major FPS drops came from having the gore mod numbers completely at max >_>

 

For some reason that shot of the shadow of the shotgun guy disintegrating into salsa is deeply hilarious to me.

 

Really amazing work here Ketmar. I look forward to seeing more maps utilising this port.

Edited March 1, 2021 by Murdoch

[Remilia Scarlet]

Quote

Warning: ignored ACSF `SoundSequenceOnSector`

Hmm, are the SoundSequence* ACS functions not implemented?  Just curious, I can find a workaround ^_^

[ketmar]

8 hours ago, Remilia Scarlet said:

Hmm, are the SoundSequence* ACS functions not implemented?

yeah, you can trust the engine here. ;-) basically, i am implementing ZDoom ACS additions when something is absolutely doesn't work without them (or in a batch, if they're close to each other). as there is no proper specs for ZDoom extensions, for each ACSF i have to dive into GZDoom code, and it is not fun at all. so there are still unimplemented ACSFs (mostly cosmetics, like sound or lighting things).

 

in this case, no "SoundSequence" APIs are implemented. it is impossible (read: i am lazy) for sectors (because only thinker objects can emit sounds; yeah, doors and lifts have invisible thinkers attached), and i didn't bothered implement others. if you'll give me a small test map, i may try to implement those (including impossible ;-) for the next build (which i plan to release this next week).

Edited March 3, 2021 by ketmar

[ketmar]

On 3/1/2021 at 11:15 PM, Murdoch said:

I look forward to seeing more maps utilising this port.

thank you. i really need to implement some planned in-engine tools to attract mappers, tho. basically, you cannot edit geometry on the fly (it is doable, but too hard to implement for now), but everything other can be edited. realtime light editing should help alot too -- this prolly will be the first thing i'll try to implement.

[Murdoch]

1 minute ago, ketmar said:

thank you. i really need to implement some planned in-engine tools to attract mappers, tho. basically, you cannot edit geometry on the fly (it is doable, but too hard to implement for now), but everything other can be edited. realtime light editing should help alot too -- this prolly will be the first thing i'll try to implement.

 

Realtime editing? Of a Doom map?! Pah! Back in my day we had to edit our maps in DEU, save them, then run them through BSP! In DOS! And it made us MEN! Or... something... 

 

Hehheh realtime editing of any kind in a Doom engine sounds pretty incredible. Keep it up.

[ketmar]

4 minutes ago, Murdoch said:

realtime editing of any kind in a Doom engine sounds pretty incredible. Keep it up.

tbh, i even have plans to implement full-featured in-engine map editor. but this work is still in early research stages. one consequence of implementing it may be freely moving sectors a-la Build (because i'll need this feature for geometry editing anyway).

 

but don't hold your breath, it may (and prolly will) take years to appear. yeah, i have HUGE roadmap for k8vavoom project, and my enthusiasm only becomes stronger over time. do not adjust your set, because we have such sights to show you! ;-)

[Remilia Scarlet]

1 hour ago, ketmar said:

i really need to implement some planned in-engine tools to attract mappers, tho. 

tbh, K8 and Doomsday are the engines I map for anymore :-P So you've at least attracted this one.

 

I'll put together a test map for the SoundSequence things. I don't need it, it was just easier to implement something with those than in another way. No biggie ^_^

[ketmar]

1 minute ago, Remilia Scarlet said:

So you've at least attracted this one.

...and if i'll give you more tools, you'll be able to create even more impressive maps, so it looks like a win-win condition. ;-)

 

2 minutes ago, Remilia Scarlet said:

I'll put together a test map for the SoundSequence things. I don't need it, it was just easier to implement something with those than in another way.

thank you! it won't hurt to have more supported ACSFs anyway, and sound sequence API looks like some easy thing to do. i just didn't hit any map that is using it (or never noticed), so i didn't bother to implement it.

[ketmar]

a-a-and... we have the first released map officially targeting k8vavoom!

The Unending!

and this is the map from @Remilia Scarlet too, so expect it to look great and play great.

what are you waiting for? grab it while it's (still ;-) hot!

[ketmar]

The Unending, three screenshots

 

lightmaps:

Spoiler

 

stencil shadows:

Spoiler

 

and shadowmaps:

Spoiler

 

so, you technically can play it in GZDoom, but hey, you will lose alot of map atmosphere!

[ketmar]

and two more shots to compare.

 

no shadows:

Spoiler

 

proper shadows:

Spoiler

 

[Remilia Scarlet]

Yeah I completely redid the lighting specifically for k8vavoom. You have no idea how much I love proper stencil shadows and the shadow maps.

[ketmar]

a-a-a-and! ladies and gentlemen! DoomGuys and DoomGals! we have something special for you today! the new build!

 

brief changelog:

Spoiler

* experimental t-junction (those annoying white dots on walls) fixer (lightmaps renderer will still have dots; sorry)
* VERY EXPERIMENTAL physics optimisatin code: it tries to avoid expensive physics calculations
  for "sleeping" objects. it may not work with some complex mods/maps, but Memorial (with ~4000 monsters)
  is playable now (at least on my core2duo); don't expect it to help things like Nuts, tho -- it can't
  improve massive slaughtermaps (due to alot of active monsters)
  this is turned on by default; if you see some strange monster movement in some mods, try to turn this off
  (options -> gampelay -> physics optimisation)
* fixed missing texture warping animation (thanks, Mr.Rocket)
* `A_Jump()` should always use dynamic label resolving
* UDMF textures scale/offset fixes
* fixed wrong condition in ceiling floodfill bug detector
* fixed rare division by zero in Dehacked loader
* added gameplay option to make monster corpses smaller (so they will hang on ledges less often)
  (off by default, go to gameplay options -> smaller corpses)
  please note that Arch-Vile may resurrect monsters stuck in the wall with this setting "on"
* implemented "Inventory.PersistentPower" decorate flag
* fixed bug in `CheckPosition()` (`A_SpawnItem*()` decorate action should not fail randomly anymore)
* implemented DECORATE rip levels for ripper projectiles
* implemented DECORATE `FriendlySeeBlocks` property
* optimise (crop empty pixels) psprite textures -- this avoids GPU memory/bandwidth wasting for huge hires psprite textures
* added experimental UMAPINFO support
* made marks on automap blink, so they're easier to spot
* gore mod: optimised ceiling blood (removed two unnecessary spawns); do not spawn ceiling blood too high; added option to disable ceiling blood drops
* various cosmetic fixes on intermission screen (better endgame detection; leave "entering" text for loading and wiping; etc.)
* interpolate player angles set by `A_SetAngle()`/`A_SetPitch()`/`A_SetRoll()` (barely noticeable, but why not? ;-)
* properly implemented `+Vulnerable` flag; fixed recently introduced bug with DamageType transfer for dying things (like explosive barrels)
* fixed several bugs/UBs found with Valgrind (thanks, id0!)
* fixed bug in png loader for paletted pngs with alpha channel (alpha is 8 bits, not 1 bit)
* added option to apply extra friction to non-moving player (to allow less 'icy' movement) (on by default, go to gameplay options -> player movement)
* added `A_SetCrosshair()` DECORATE API
* fixed bug in `SV_FindRelOpening()` with 3d floors (bad lowest floor detection)
* implemented more GZDoom ACS HUD flags (nowrap, alpha)
* load archive "keyconf" after "mapinfo", because it should override mapinfo's gameinfo section
* more DECORATE weapon pickup states ("TryPickupWeapon", "PickupWeapon") -- this is k8vavoom DECORATE extension
* oops! savegame didn't saved current skill
* fixes to Boom transparent door rendering hack (it wasn't really working before)
* slightly better "automatic jump out of the water" code (should be more consistent, and easier to use)
* added menu options to control maximum pickup flash time, and maximum damage tint intensity (misc options)
* looking straight up to the sky in huge open areas should not render the whole map anymore

 

download link is in the first post, as usual.

 

most interesting new features:

* t-junction fixer -- no more pesky white dots! (only for stenciled/shadowmaps for now, sorry).

* default renderer is "shadowmaps" (i.e. if your GPU supports shadowmaps, the engine will select shadowmap renderer on the first run; WARNING! if you already have "config.cfg", nothing will be changed).

* physics optimisation -- now you can play Memorial with its 4K monsters.

[ketmar]

Spoiler

 

@-TDRR- ping. ;-)

 

 

Edited March 4, 2021 by ketmar