k8vavoom: no good thing ever dies!

[ketmar]

i am still too lazy to figure a way to calculate proper biasing, but i found that if i will turn on shadowmap filtering, moire mostly goes away. sure, it's not how it Should Be Done, but hey, it works! well, almost. it doesn't work right for shadow bluring (here i need a proper value), yet it doesn't look very bad.

 

also, i implemented proper texel sampling, so shadow blurring works much better now, because it really samples the nearby texels instead of going by some random distance. to make better blur i still need to calculate proper weights for samples, tho.

 

no screenshots this time, we have too many of them already. ;-)

[ketmar]

oh, i got the new idea how to fight a moire pattern (which you can see as a rectangular pattern, but let's call it "moire" ;-). here's what i did in the last commit:

Spoiler

use constant distance from a shadowmap texel to the light source. most moire is because we're hitting different parts of the shadowmap texel for different screen pixels. but in the end of the day, the distance to the light for all those texels is the same (because they all hit the same shadowmap texel). so let's do it in reverse: find out which texel we're sampling, snap direction so it always points to the fixed texel part, and find the intersection of this new direction and the surface we're currently rendering. finally, calculate distance using our new point. this way, the distance will always be the same, and we can get away with a small constant bias.

actually, it is slightly more complex than this: for now, i'm calculating distance to four shadowmap texel corners, and use the minimal one.

the moire pattern seems to be gone. it needs more testing, though.

 

hidden under the spoiler, because this is math mumbo-jumbo, and you don't need to understand it to enjoy new renderer. ;-)

[ketmar]

made new moire-free shader with real bilinear shadow filtering almost as fast as the old one without filtering. let's hope that it works right -- it is a fuckin' mess of includes with defines, The Great Macroprocessor abuse, which generates 12000+ lines of shader source. lol. sure, most of that source is never comipled (ifdef-ed out), so the shader is not that huge (otherwise it won't be that fast). let's hope that some shitty drivers won't preform a quirkafleeg on that.

 

for you all it means that you will be able to get almost the same FPS as you've seen on my screenshots, but with bilinear-filtered shadows, and without moire pattern at a distance. also, new moire removing scheme greatly reduced peterpaning (if you will turn off shadow filtering, peterpaning will disappear almost completely).

 

also, shaders are compiled "on-demand" now. startup times are still huge, but at least you won't pay for something you won't going to use.

 

 

p.s.: for those building git master -- i know that shadows are partially broken now. i borked cubemap creation, that's why shadows are blinking. i'll fix it later.

Edited December 9, 2020 by ketmar

[ketmar]

and more screenshots for you. standard, E1M1, but i turned off ambient lighting for better effect.

 

shadows from BRNSMAL, from the barrel, and if you will look closely, you will see player shadow too. ;-)

Spoiler

 

Edited December 9, 2020 by ketmar

[ketmar]

of course, broken shadows was not due to bad cubemap, but due to forgotten texture switch. now there is only one problem left: "shadow jumping". sometimes when geometry changes, shadows "jumps" for a frame or two. i don't know why yet. i'm not using any cascading, and stored distances are linear. i haven't the slightest idea. but it doesn't happen too often, so the thing is... tolerable.

 

also, let's hope that shader compilers won't blow up from 10000+ line shaders. ;-) ah, don't worry, it is a mess of macro includes, and most of those lines aren't compiled. but shaders are still big. so big that i had to add a progressbar to shader loader. this is the price for getting bilinear filtering run with the speed of "no filtering" mode. yeah, i had to perform manual filtering in the shader. and i can't even use `textureGather()`, because it is from OpenGL4.

 

ah, yes: shadowmaps would work with OpenGL 2.1. if your GPU won't allow you to use stenciled shadows, it may be still possible to use shadowmaps. yet it will prolly be a slideshow. ;-)

[seed]

1 hour ago, ketmar said:

ah, yes: shadowmaps would work with OpenGL 2.1. if your GPU won't allow you to use stenciled shadows, it may be still possible to use shadowmaps. yet it will prolly be a slideshow. ;-)

 

I was just about to ask about this, since you know, this is advanced stuff, even if such hardware could run it in some capacity it will probably run at a blazing 5fps, heh.

[ketmar]

@seed actually, it's not that advanced. ;-) the problem (as usual) is in fillrate. cubemap has 6 floating point textures and 6 depth textures (i'm using separate depth textures for each face, so i can clear the whole cube before using -- this is slightly faster, as some hardware can keep clearing some faces in background, while using the first one), and we have to clear them for each light source. sampling cubemap is quite fast (especially without bluring) then. so you may still have a playable FPS. you can also turn off dynamic lights, this will leave only lights from map decorations (such lights detected as static ones).

 

so you *may* still have something playable. i would be very interested to hear from people with old GPUs. i mean, if it will still be a slideshow, then there will be no reason to keep it 2.1-compatible, and i may bump shadowmap requirements.

Edited December 10, 2020 by ketmar

[ketmar]

also, hey! i want 2021 cacoward for this! 'cmon, it's not written in Unity, and this alone should be a reason to get a cacoward! ;-)

 

Spoiler

just a joke.

 

Edited December 10, 2020 by ketmar

[Remilia Scarlet]

I've got a question regarding ACS compatibility...

In GZDoom, if I call Autosave() and then die, I respawn at the autosave point.  I don't seem to in k8vavoom.  In the console I see messages such as "Log: Game autosaved to slot #2", but also some that say "Log: AUTOSAVE: cannot create checkpoint, perform a full save sequence".  Is this expected?  And how can I load an autosave?  I don't see them in the Load Game menu, and I can't quickload them.

 

 

[ketmar]

24 minutes ago, Remilia Scarlet said:

Is this expected?

yes. sometimes the engine figures that it can get away with saving only player state -- this is called "checkpoint". usually it does this on map start, if there is no hub map. this is pure informational message, to tell you that checkpoint creation is impossible, and the engine will revert to a full save.

 

24 minutes ago, Remilia Scarlet said:

And how can I load an autosave?  I don't see them in the Load Game menu, and I can't quickload them.

that's why i added help to menus. ;-) in load menu, there is a help text that will tell you to press "tab" to switch between normal saves and autosaves. ;-) there will be saves marked as "AUTO:", and you can load them as usual.

 

(also, you can delete saves by pressing "DEL" two times. dunno if anybody knows about that. ;-)

 

24 minutes ago, Remilia Scarlet said:

In GZDoom, if I call Autosave() and then die, I respawn at the autosave point.

k8vavoom doesn't load any save on its own, and it will never do. the save is there, but you have to load it manually. this may be inconvenient at times, but i strongly believe that the engine should not perform any loading on its own will: dying means restarting map exactly as in vanilla. this design decision comes from the same mindset as limited save slots. (ok, save slots are not that limited, you can use more from the console; but UI won't support more slots.)

 

p.s.: also, note that the engine may decide to reuse autosave slots at any time, so don't expect them to last forever. or it may decide to not reuse, and fill your autosaves with identical autosave points. ;-)

Edited December 12, 2020 by ketmar

[ketmar]

here is something completely different interesting for you. while my work on shadowmaps is far from complete (it's not even a pre-beta yet), i thought that i can give you a taste of it right now. because why not?

 

please, note that this is not the usual build: it is very WIP code, it may crash, burn, and simply refuse to work. ;-)

 

to turn on shadowmaps, select "stencil shadows" renderer, then go to "shadowmap options" submenu, and turn on shadowmaps. don't worry: even if your GPU cannot suport stencil shadows, but can support shadowmaps, the renderer will still be selectable. it won't appear only if your GPU is unable to support anything besides lightmaps.

 

please, don't report bugs with shadowmaps yet: they're expected to glitch in various fun ways. the code is still PoC-quality. this is here so i can stop making screenshots, because you'll be able to do it yourself. ;-)

 

have fun.

 

shadow build

[ketmar]

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

But then I noticed it again in map17 of Doom 2 with a lift (my level does not have a lift).  Basically, the first screenshot shows how the floor should look.  But when the lift is moving, this fake floor (brown in the 2nd screenshot) gets rendered.

this was indeed a bug introduced by "bridge detector". the option to turn it off wasn't in the menu, tho (misc/bridge is slightly another thing). so i added it to menu, and turned it off by default too (because it does more harm than good). thank you!

[Gunrock]

Great job as always Ketmar;)

[ketmar]

some more pictures, mostly about FPS.

 

stenciled lighting (shadow volumes):

Spoiler

 

shadowmaps, no blur:

Spoiler

 

shadowmaps, bilinear blur:

Spoiler

 

sure, there is no much difference between blur/noblur on those screenshots, i just wanted to show how blur impacts heavily-lighted scene. yep, this scene is really heavy on the lights with huge radiuses -- that's why i'm often using it to test things. it was created for lighting w/o shadows (and with "r_shadows 0" it is 60 FPS, of course).

 

i'm almost sure that i can do bilinear filtering even faster with unrolled cubemaps, but i think i'll leave it for some future builds (mostly because i still don't understand how to do it properly ;-).

 

some estimates: shadowmapping is usually faster for (many) huge lights, and for complex map geometry. for simple geometry and the usual lighting from standard decorations, shadowmapping is more-or-less of the speed of shadow volumes (most of the time it is slightly faster, tho). of course, if your GPU cannot render shadow volumes at all, shadowmapping is infinitely faster. ;-)

[Mr.Rocket]

/Mr.Rocket flips the f@k out..

 

 

Edited December 18, 2020 by Mr.Rocket

[ketmar]

shadows and textures, it's all wrong... sometimes. ;-)

 

the fun thing about two-sided walls in Doom is that they have their textures flipped on the other side. it is barely noticeable with normal rendering, but it is noticeable with shadows.

 

this is how "cell from cell screenshot" looks from the top:

Spoiler

 

and this is how it looks from the inside:

Spoiler

 

as you can see, there is something wrong with the shadows. and ceiling grates are not the same.

 

and this is how it looks with "shadow flip fix":

Spoiler

 

now we can see where our main light is, and the picture looks much more logical.

 

and another screenshot, with applied "flip fix". there were no shadows from the grates, and now the shadows are there. (please, note that this map wasn't created for such lighting, i'm only using it to test my renderers; this is absolutely not what map author wanted it to look like!)

Spoiler

[Mr_SquarePeg]

Hey @ketmar I really like what you are doing with K8vavoom. I have a question - Is there a dedicated discord or something for K8Vavoom?

[ketmar]

how to script custom actions without ACS. this is actually the title of the post.

 

yesterday i wanted to implement Duke3D-like "quick kick" feature for one of my private mods. the easiest way to implement it (without temporarily changing the current weapon) is to add overlay to each weapon, and ACS script that puts something like "ActivateQuickKick" into inventory, to bind "puke" to soma key. overlay checks inventory in the loop, and performs the attack if "ActivateQuickKick" is there. (yep, both primary and secondary fire are used; i could use "zoom" key instead, but i forgot about it.)

 

ok, now we have two problems here. first, k8vavoom supports only one weapon overlay, which renders above the weapon itself. ah, what is that "weapon overlay", you may ask? obscure decorate feature: if you will define weapon state named "Display:", that state will be run as a "separate task" when the weapon is active, and its sprites will be rendered too. but for kicks, we definitely need an overlay that will be rendered under the weapon sprite.

 

(note: in GZDoom, there is generalized visual overlay system with priorities; dunno, i'm still not sure if i want to have that, so it is not implemented in k8vavoom for now.)

 

ok, solution to this problem is easy: i just added "DisplayOverlayBack:" state, so we can have both "over" and "under" weapon overlays.

 

now, second problem: i absolutely don't want to write any ACS -- mostly because it should be compiled by separate utility; it sux. also, creating ACS script only to puke it, so it could give some inventory item? 'cmon, it is way easier to add a console command to do that, and then bind it to a key. so i did: "ConsoleGiveInventory <name> [amount]". but this can be used to give the player anything in the game, which is not what we want. so, i added decorate flag "+Inventory.k8AllowConsoleGive". only items with this flag could be given from the console.

 

ok, we're almost there, and without any ACS. there is one thing that needs to be solved, tho: "quickkick" code part is exactly the same for each weapon, and should be copypasted into each weapon actor. in all 7 new weapons. and then i will change something, and will forget to copypaste it again. DO NOT WANT.

 

as you know, "#include" works only on top-level decorate, not inside actor definitions. but why? eh, just because it was done this way. it is quite hard to parse "#include" in actor definition, tho (it will be parsed as two tokens, "#" and "include", and this complicates things a little), so i opted to hack a simple solution: "stateinclude <filename>" command. yep, it works only inside state definitions, but i'm ok with it. now i can put my "quickkick" code into separate file, and simply include it in any weapon i want. no more code pasta, no more desync problems.

 

of course, the same thing can be implemented with VavoomC (and i bet GZDoom people would use ZScript without any second thought). but i still believe that this is The Wrong Thing to do. decorate is VERY powerful, and huge subset of it is [G]ZDoom-independend (while ZScript absolutely cannot be implemented in anything that is not GZDoom, and to implement VavoomC you have to be Vavoom/k8vavoom). this simple decorate extension is trivially implementable, so any sourceport with decorate state support can have the feature added in 15-30 minutes. literally.

 

this also allows alot of other uses. as given item runs its "pickup" state, you can script alot of things there. some kind of "mana airstrike" for example, but only if you have enough mana in the inventory. and so on. and you don't need to mess with ACS for inventory management anymore.

 

of course, k8vavoom doesn't enjoy a huge modding crowd, and i don't expect this feature to be used in mods. (throw in some ACS and allow your mod to run with Zandronum/other-ZDoom-forks, or make a shortcut and stick to one exotic sourceport? hm... it's really hard to choose! ;-) and sorry for this wall of text, i deliberately didn't hid it in spoiler. i may be one of the last proponents of "let's have cross-port actor definition languge" agenda, but i still believe that decorate is NOT OBSOLETE, no matter what GZDoom people think about it. this very simple decorate extension can open alot of possibilities, and it is trivially implementable in other sourceports. DECORATE MODDERS OF THE WORLD, UNITE! ;-)

 

 

p.s.: i was planning to write a huge post about the sad state of crossport Doom modding, but... eh. i just re-read this topic again, and dropped the idea. i think we should accept the fact that Doom modding scene will never unite again. we will always have "GZDoom scene", "Zandronum scene", "Eternity scene" (where it is, btw? ;-), and so on. and those scenes will diverge even more over time. so it goes, i guess...

[ketmar]

2 hours ago, Mr_SquarePeg said:

Hey @ketmar I really like what you are doing with K8vavoom.

thank you!

 

2 hours ago, Mr_SquarePeg said:

I have a question - Is there a dedicated discord or something for K8Vavoom? 

nope. at least not the one i'm participating in. maybe someday we'll get a dedicated site with forum and wiki, but for now, this thread is The Only Official k8vaoom Home. ;-)

 

(i am not using discord at all, btw. i'd like to have IRC channel for k8vavoom, tho, but i don't think that we'll have alot of people there.)

[ketmar]

happy new year, all! stay calm, don't forget to oil your shotguns, and be happy!

 

(and yes, there will be new build in new year. with quite a long changelog)

[Mr.Rocket]

Happy New Year All!!! ;)

[Gunrock]

Happy New Year!

[Remilia Scarlet]

Just noticed something with a MAPINFO definition I have.  k8vavoom complains that the Sky2 line is too long and quits.

map MAP06 "Sacrificial Altar" {
    Author = "Remilia Scarlet (Alexa Jones-Gonzales)"
    LevelNum = 1
    Next = MAP07
    Music = "music/map06.ogg"

    LightMode = 3
    SmoothLighting
    NoJump
    NoCrouch
    CheckSwitchRange

    ForceNoSkyStretch
    DoubleSky
    Sky1 = "textures/sky1-fg.png", 0.2
    Sky2 = "textures/sky1-bg.png"
}

Quote

Error: Sys_Error: Script error at oagb-rc1.pk3:mapinfo.txt:110: Name 'textures/sky1-bg' is too long

 

[ketmar]

2 hours ago, Remilia Scarlet said:

Just noticed something with a MAPINFO definition I have.  k8vavoom complains that the Sky2 line is too long and quits.

yeah, i don't think that it supports long texture names there. i'm not even sure that it is legal -- i mean, Vavoom tries to be quite strict about allowed texture names (actually, all lump names), and i am usually relaxing those restrictions only when i encounter several maps with such "non-standard" use of things. mostly because there are alot of places where i need to use different texture searching algos, and texture manager code is a mess (i wasn't very knowledgeable of Vavoom internals back then; i should remove all crap i dropped in there and rewrite some parts, but i am really afraid of doing that, because each hack i added was to make some map working, and of course i never made a list of problematic maps ;-).

 

anyway, i see no reason to not allow long textures there, so i'll prolly fix that for the upcoming build. thank you!

 

p.s.: actually, it looks like it is able to load long textures there, i just forgot to relax parser restriction. just pushed the fix, it should work now (i hope ;-).

[TheMightyHeracross]

Hey, just built this on Debian 10.7. Works pretty nice so far. Just played Strife up to the prison mission and have a few bugs:

 

• Klaxon alarms don't seem to go off, though enemy behavior otherwise seems fine
• The weapons and ammo screen is a bit misaligned (it gets worse at lower resolutions):

• The poison crossbow seems to use the same logic as the dagger when determining whether nearby acolytes see you hit, meaning that sometimes acolytes will be alerted when you kill something with the poison bow when they shouldn't. For example, if you kill the acolyte guarding the first secret in the governor's mansion with the poison crossbow, the acolyte near the exit will be alerted when he shouldn't.

 

[ketmar]

19 minutes ago, TheMightyHeracross said:

Hey, just built this on Debian 10.7. Works pretty nice so far.

thank you! and for your reports too. ;-)

 

just a note: i don't really know how Strife should work. first, i have Strife VE, but i don't know if something was changed there from the original DOS version. second, i need a step-by-step guide to reproduce behavior bugs (preferably with VE, but maybe GZDoom v3 is ok too), with "what is wrong, and what was expected", because otherwise it will be hard for me to check it.

 

i really apreciate all non-Doom reports, and i will gladly fix other games, but most of the time i really need you to hold my hand here. ;-)

 

also, yep, HUDs for non-Doom games are not on par with Doom HUD (this includes intermission screens). this is because in Vavoom all HUDs were done with alot of copypasta. while i factored out some code, most of the pasta is still intact. Doom HUD got most love, others are still WIP, especially at high resolutions and different aspects. sorry for that, i promise i will eventually fix it! ;-)

 

anyway, thank you alot! i will try to look into the ussues myself, and maybe i'll be able to fix them by comparing VE/GZDoom/k8vavoom logic and spotting the differences.

Edited January 4, 2021 by ketmar

[TheMightyHeracross]

VE is based on Chocolate Strife so you should be able to reference it for "correct" behavior. (There is one boss, the Loremaster, that is bugged in Chocolate Strife and VE, but otherwise it's accurate AFAIK).

 

Reproducing the alarm bug is pretty simple, just play the Sanctuary mission (the first quest) and you'll notice that alarms don't go off in the base.

 

If you want to reproduce the crossbow issue, do this:

• Get a crossbow with poison arrows
• Go to this spot in in the town.
• Shoot the guy on the right with the poison arrow. In k8vavoom, the guy on the left starts going after you. In DOS, Chocolate, VE, and ZDoom he doesn't.

Edited January 4, 2021 by TheMightyHeracross

[ketmar]

3 minutes ago, TheMightyHeracross said:

VE is based on Chocolate Strife so you should be able to reference it for "correct" behavior. (There is one boss, the Loremaster, that is bugged in Chocolate Strife and VE, but otherwise it's accurate AFAIK).

great, thanks!

 

3 minutes ago, TheMightyHeracross said:

Go to this spotin  in the town

for some reason i cannot see the picture. you can use "mypos" in console to get current coordinates (you can use "-logfile filename" to write console log to file, or run k8vavoom from a terminal).

[TheMightyHeracross]

Log: >mypos
Log: Map Hash (sha): 8f096be795e5eeda884a99a53e7783badd0715cc455036bf6488aad9
Log: Map Hash (md5): 2a6e4b7bd9e5b448bbaab4a31d9084ef
Log: sub: 362; sector: 8
Log: pos:(1663.62,3913.41,-32)  angles:(332.096,3.509)
Log: +map map02 "+warpto 1663 3913 -32"

It's the outside of the entrance to the Governor's mansion.

 

I'm a big Strife fan and Strife-supporting ports are few and far between (I think the original Vavoom was the first?), so I'll definitely be glad to test it out more in this port.

[Remilia Scarlet]

2 hours ago, ketmar said:

i'm not even sure that it is legal

GZDoom accepts it and it works as expected, so I'm guessing it's legal.  But sweet, thank you!  This is needed for the Oops! All Greyboxes! project, which will be released next week.  I wanted to make sure it worked with k8.