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

k8vavoom: no good thing ever dies! (2021, Mar 04 build)

Recommended Posts

1 hour ago, YeOldeFellerNoob said:

What I could suggest is "Fake Wall Shadows" (Sprite and 3D enemies make shadows on walls)

this is what we'll have in the new build: post with the picture. ;-)

Share this post


Link to post
17 hours ago, ketmar said:

this is what we'll have in the new build: post with the picture. ;-)

So THAT was what it was called! I thought they were simply called Sprite or Model shadows! I cannot wait to absolutely and utterly destroy my PC when this comes out!

Share this post


Link to post

ketmar actually lives in the future so he'll be able to create a patch to keep that from happening before he creates the patch. ;)

Or something like that, I'm still trying to catch up.

Share this post


Link to post
6 hours ago, YeOldeFellerNoob said:

So THAT was what it was called! I thought they were simply called Sprite or Model shadows!

and you are right. it's simply impossible to render them with shadow volumes algorithm, so i implemented 3rd renderer, based on shadow maps algorithm. shadow maps using rendered picture to perform very simple raycasting, so anything that can be rendered can cast a shadow. the downside is visible texels on shadow edges. you can see that even in many modern games; it's highly blured, but it is often still possible to see "shadow texels". and i cannot blur it alot, because i still want the whole thing to work on OpenGL 2.1 (and weaker GPUs). anyway, i implemeted very simple bilinear filter, it looks quite nice, and is not dog-slow.

Β 

the whole thing is still slightly buggy, but i think it is "good enough for release". ;-) i'm just trying to spend several days without coding anything, only playtesting the build. and it's hard to not code. ;-)

Edited by ketmar : some typos

Share this post


Link to post

WARNING! my Wine install somehow got broken, and OpenAL cannot find any sound devices anymore. i don't know why, and i hope that you will have sound working. please, report here if it isn't.

Β 

i can keep adding "Yet Another Small Feature" for eternity, so let's Just Do It Now: here's the new build!

Β 

brief changelog: (there are more changes, i just got tired of putting 'em there ;-)

Spoiler

* I'M REALLY SORRY, BUT YOUR OLD SAVES ARE TOTALLY BROKEN. it's a good thing that we don't have a huge userbase, i guess.
* (except checkpoints at the start of a map, they may still work)

* experimental shadowmaping lighting model (should work with OpenGL 2.1)
* do not spawn monsters from ACS with "-nomonsters" (Remilia Scarlet requiest)
* fixed a long-standing bug with occasional texture flipping (it was really hard to notice, tho ;-)
* some optimisations in texture queries
* various rendering optimisations (less state switches, less BSP walks, etc.)
* added hack to better limit number of decals on one wall segment, to avoid massive slowdowns with maximum gore
* limited maximum number of gore blood spots (proximity check), to avoid spawnin zillions of them (this was causing massive engine slowdowns)
* draw crosshair on top of everything (control with "crosshair_topmpost" bool cvar)
* fixed bug in `BSPTraceLine()` return args
* added `SXF_MUZZLE_TRACE` flag to `A_SpawnItemEx()` to use with muzzle entities (so they won't spawn inside or behind a wall)
* fixed some small bugs in model rendering (mostly harmless)
* added option to use S3TC texture compression (mostly useless, but why not?) by default, hires textures will be compressed
* added option to control adaptive VSync (cvar was there for years, but no menu option)
* slightly faster dynamic light management (i hope ;-)
* fixed some bugs in parsing compat flags in old mapinfo format
* turned off "transparent door floor fix" (it tried to fix some vanilla rendering hacks, but it is wrong alot of times; will rewrite it later)
* skip vanilla render fixes for extended UDMF maps
* allow zero tags in Boom "Static_Init" (this fixes Boom sky change in many maps)
* fixed several small bugs (and memory leak) in UDMF height-based slope creation
* fixed some bugs with translucent surface rendering (invalid surface/sprite rendering order)
* fixed binding of mouse buttons in UI (thanks, Mr.Rocket and Remilia Scarlet)
* added some sanity checks to maploader (put here to make the changelog bigger)
* added `A_CallSpecial()` (k8vavoom has its own `A_ExecActionSpecial()` for that, but let's be compatible)
* some fixes in portal rendering (better portal frustum transfer; yet mirrors are still partially broken)
* clip geometry with mirror plane (this should fix rendering of mirrors without "big back sector")
* convert `SectorPointLight` and company to static lights, if possible (lightmapped renderer will not update 'em with new sector lightlevels, tho)
* player sound definitions should be case-insensitive
* added `Player.SoundGender` decorate player property
* added `Player.GruntSpeed` decorate player property
* added support for `Player.DamageScreenColor` for custom damage types
* added `GetCrouchFactor()` decorate API
* implemented getters/setters for `APROP_MaxStepHeight`, `APROP_MaxDropOffHeight`, `APROP_DamageType` properties
* reworked state change logic a little, some broken mods (especially weapon ones) should work slightly better
* made `A_WeaponReady()` more compatible with ZDoom implementation
* implemented "+MirrorReflect" and "+AimReflect" decorate flags
* added VavoomC API to create new color translations (it is now possible to port "UniversalEntropy" GZDoom mod to k8vavoom, except sound pitch change)
* added "options->misc->flip corpses" option to randomly flip monster corpses
* allowed long texture names in "sky2" (thanks, Remilia Scarlet)
* fixes to bouncing code (bouncing missiles should stuck much less now)
* fixed sound propagation bug (closed sectors weren't blocking)
* fixed IDIOTIC bug with dir -> angles conversion (straight vertical dirs had inverted pitch angles)
* fixed bug in internal blockmap builder (it was using 16-bit ints for linedef numbers, so blockmaps for huge maps were all wrong)
* Strife poison bolts should not alert monsters (thanks, TheMightyHeracross)
* Backpack will not give ammo for another games, nor some "invalid" ammo anymore
* fixed `A_Warp()` (it was completely wrong)

Β 

@-TDRR- ping, as requested. ;-)

Β 

p.s.: promised mods (Zan and randomizer) will be published slightly later.

Edited by ketmar

Share this post


Link to post

also, i'm trying on hack to make huge maps playable. like, there is Memorial, for example, with 4000 monsters, and it runs in single-digit FPS with k8vavoom. and with this hack, it runs at 45-60 FPS now (on my core2duo 3GHz). the hack is simple: don't run physics for "sleeping" objects. there are alot of objects that rests on the floor, and they don't need any physics processing (this includes inactive monsters). the engine tries to detect that, and bypass most of the VM code for them. this is quite hard to implement right, though, because Vavoom physics code does alot more things than simple velocity changes (it has some game logic processing too), so it may break with some mods, or maps with conveyors/sector effects, or such. still, the rough implementation is there, and Memorial is quite playable.

Β 

but don't expect this to allow you to play all slaughterwads out there. ;-) in slaughterwads, there are usually alot of active monsters, and they have to use full-featured physics code. still, exploration-style maps with several thousands monsters, most of which are inactive (and being killed when you'll meet them) should be playable. i.e. nuts.wad will still work with zero FPS, but you'll be able to enjoy Memorial, or Openworld Doom.

Share this post


Link to post

uploaded quickfix for netplay. sorry, it is somewhat broken again. ;-)

Share this post


Link to post

Hi, while the shadows look freaking amazing, fucking awesome! especially when the player jumps down in cubie holes and what not. ;)

Β 

However, currently, in my map, which you have a copy of, the teleports/slip gates (should have an animation), but they don't for some reason.Β 

They are purely 3dfloors and translucent lines.Β ~ I used the "warp" animation so,Β animdefs.txt,Β so that would be where to look.

warp2 flat imagename int variable.

Β ~ the animation worked in all previous versions. although, hmm it doesn't seem to be working in the last test build.

Unless they're disabled via menu somewhere and I don't know it yet.

Β 

Β 

Thanks

Edited by Mr.Rocket

Share this post


Link to post
5 hours ago, Mr.Rocket said:

the teleports/slip gates (should have an animation), but they don't for some reason.Β 

oops. i forgot to set one flag, and the animation broke. there is nothing wrong with your map, it's my fault. fixed, thank you! will work again in the next build.

Β 

5 hours ago, Mr.Rocket said:

Hi, while the shadows look freaking amazing, fucking awesome! especially when the player jumps down in cubie holes and what not. ;)

thank you! yeah, i like playing with shadowmaps too. sprite shadows DO make a huge difference, actually. ;-)

Β 

2 hours ago, YeOldeFellerNoob said:

Tried out the Shadowmaps and I am literally pissing my pants from the detail, even though my PC was running it at 12 or 5 FPS.

glad you like it! thank you!

Β 

it's sad that your GPU cannot do it in realtime, tho. i think you already tried it, but just in case: setting "shadowmap blur" to "none" may give you a noticeable FPS boost. bluring is quite expensive even for newer GPUs, and may be a total killer for older ones (shader code contains alot of conditional branches, and older GPUs are not very good at such code).

Β 

sadly, this is prolly as much as i can do to make it faster. the shader is already a freakin' mess of almost unmanageable inlined copypasta. also, shadowmaps are quite demanding to GPU memory bandwidth too. there's almost no thing i could do with that while staying OpenGL2.1-compatible. and i don't want to bump OpenGL requirements yet.

Share this post


Link to post
9 hours ago, ketmar said:

oops. i forgot to set one flag, and the animation broke. there is nothing wrong with your map, it's my fault. fixed, thank you! will work again in the next build.

Ah ok, cool!

Β 

In other news, I found out I'm going to have to update the launcher a bit once again. I never finished the map selections per IWAD. eg the amount of maps that should be displayed when a given IWAD is selected. (most are fine though on iwad selection)

I'd also like to have it so it would auto populate with some default settings (on first run), at some point. ~ which would require detected exe and iwad without user input. It's a small launcher but there's needs to be more going on there than one would expect.

Hopefully it will be ready sometime after next build. ;)

Β 

Edited by Mr.Rocket

Share this post


Link to post
21 hours ago, ketmar said:

it's sad that your GPU cannot do it in realtime, tho. i think you already tried it, but just in case: setting "shadowmap blur" to "none" may give you a noticeable FPS boost. bluring is quite expensive even for newer GPUs, and may be a total killer for older ones (shader code contains alot of conditional branches, and older GPUs are not very good at such code).

Β 

sadly, this is prolly as much as i can do to make it faster. the shader is already a freakin' mess of almost unmanageable inlined copypasta. also, shadowmaps are quite demanding to GPU memory bandwidth too. there's almost no thing i could do with that while staying OpenGL2.1-compatible. and i don't want to bump OpenGL requirements yet.

Luckily, I didn't have to! It was because of the map pack I was using. And, out of curiosity, I ran Heretic and that, not only ran fine with Shadowmaps, getting little declines to about 40 or 45, with the most I could get was about a 50 or 55, or probably 60,Β which is great in my books, but also looks awesome. I would say gorgeous, but there are not a lot of dynalights. However, the lighting from the wand and the torches illuminating the world, unlike DOOM, makes it the best and only way to see if ShadowmapΒ runs on your PC.

Share this post


Link to post

without bilinear bluring it should be solid 60, i believe. yet i'm playing with bluring too, because little slowdowns are almost unnoticeable.

Β 

1 hour ago, YeOldeFellerNoob said:

I would say gorgeous, but there are not a lot of dynalights. However, the lighting from the wand and the torches illuminating the world, unlike DOOM, makes it the best and only way to see if ShadowmapΒ runs on your PC.

yeah, Hexen and Heretic augmented with strategically placed dynlights should look awesome. that fantasy medieval setting begs to be lit by various flickering lights, and for scary shadows. ;-) maybe someday somebody will do that. maybe after i'll implement in-engine tools to edit lighting in real-time.

Β 

p.s.: also, if you really want to play some GZDoom mappack with alot of dynlights, you can turn off shadows with "r_shadows 0" console command. sure, there is little sense in doing that, and it's prolly better to simply use GZDoom for such maps, but just in case you want to... (there is menu option for that somewhere too, but i forgot where it is. ;-)

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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 by ketmar

Share this post


Link to post
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

lwG8fu8.jpg

VxCwSF4.jpg

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

Share this post


Link to post
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 by ketmar

Share this post


Link to post

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.

Share this post


Link to post
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 by ketmar

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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. ;-)

Share this post


Link to post

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. ;)

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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". ;-)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×