k8vavoom: no good thing ever dies!

[Cacodemon345]

This patch inside the zip should allow k8Vavoom to be compiled with GCC on FreeBSD (and other BSDs).

 

freebsd-patch.zip

 

Edited October 12, 2020 by Cacodemon345

[ketmar]

3 hours ago, Cacodemon345 said:

This patch inside the zip should allow k8Vavoom to be compiled with GCC on FreeBSD (and other BSDs).

thank you! applied, and pushed to the master.

[ketmar]

5 hours ago, Mr.Rocket said:

Hey, sorry I don't want to derail or anything

you aren't! ;-)

 

5 hours ago, Mr.Rocket said:

is there a secret console command of some sort in which I can turn the HUD off?

~ the player weapon HUD.

"r_draw_psprites" cvar controls rendering of psprites (HUD weapons).

"r_statusbar_draw" cvar controls statusbar/FS HUD rendering. but turning off statusbar will not do anything good in non-FS HUD mode (it won't break, it will just render nothing there, so you'll get a black strip instead of statusbar).

 

p.s.: you can create a bind like this for screenshots, for example:

bind "/" "toggle r_statusbar_draw ; toggle r_draw_psprites ; wait 1 ; screenshot ; toggle r_statusbar_draw; toggle r_draw_psprites"

 

Edited October 12, 2020 by ketmar

[ketmar]

8 hours ago, 3t0 said:

Any simple explanation?

i strongly believe that compilers should be GPLed (and most other software too). i can tolerate alot of non-GPL software, of course, and even some non-GPL compilers (DMD, because there is no GPL compiler with feature parity), but not LLVM and anything based on it. GPL OR DIE! ;-)

Edited October 12, 2020 by ketmar

[3t0]

1 hour ago, ketmar said:

i strongly believe that compilers should be GPLed

 

understood

[Mr.Rocket]

I'm still trying to figure out why my player/weapon sprite is bouncing all over the place on any movement.

I've gone through every option and basically disabled everything and it still does it.

My newer video card drivers? my have something to do with it, I'm not sure though. 

If I run the old Vavoom the issue doesn't happen.

 

I could send you my conlog if you think it could help?

[ketmar]

2 hours ago, Mr.Rocket said:

I could send you my conlog if you think it could help?

yes, sure. also, run it with "+gl_dump_extensions 1 +gl_dump_vendor 1", please. and tell me which build is ok, to check diffs. and maybe be ready to test some private builds too. ;-) it seems that this is the bug other people told me about here, but i absolutely cannot reproduce it, and have absolutely no clue what may cause it. so if you have a build that surely works, and you are ready to test several intermediate builds, we may try to bisect it. it will help alot.

[Mr.Rocket]

3 hours ago, ketmar said:

yes, sure. also, run it with "+gl_dump_extensions 1 +gl_dump_vendor 1", please. and tell me which build is ok, to check diffs. and maybe be ready to test some private builds too. ;-) it seems that this is the bug other people told me about here, but i absolutely cannot reproduce it, and have absolutely no clue what may cause it. so if you have a build that surely works, and you are ready to test several intermediate builds, we may try to bisect it. it will help alot.

 

Is there a list of older precompiled binaries somewhere that I could have access to?

I have a new drive and only have 4 previous versions to test with, all of which have the same problem with the psprite jitter.. 

The video card I'm using is an Nvidia GeForce GTX 1660 Super, with most recent game ready drivers. I don't know if Vulkan has anything to do with it.

Windows10 Pro 64bit

k8vavoom_550930 and Doom2.wad

Anyway here ya go: conlog.zip

 

 

Thanks

Edited October 13, 2020 by Mr.Rocket

[ketmar]

@Mr.Rocket replied with PM.

[Cacodemon345]

So I was playing Doom -1 with k8vavoom and I noticed two things:

1. In the Cyber Showdown map (MAP05), some windows are invisible.
2. In the Zeta Quadrant map (MAP06), the sector pull effect is too weak as compared to GZDoom/PrBoom-plus.
3. In the same area, the bridges are invisible.

Edited October 13, 2020 by Cacodemon345

[ketmar]

yep, windows and bridges are (usually) gross rendering hacks, hard to support in hw mode. gzdoom renderer is full of mess just to support those things, and still there are cases when it fails. i don't want (read: i don't have enough resources) to turn k8vavoom renderer into totally unmaintainable pile of smelly crap, so i added several hacks to support some cases, and simply pretend that other cases are irrelevant. ;-)

 

as for pull effects (and winds, and various kinds of transporters) -- it is due to k8vavoom being (the only) freestep engine. original code is tightly coupled with 35 FPS playsim update rate, but k8vavoom updates playsim by arbitrary steps (usually much smaller that 1/35 sec). due to this, effects with hard timing are... well, hard to emulate properly. i spent alot of time trying to emultate the original effects, but it is simply not possible with the curent engine architecture. the thing is that if i fix some wrong cases, some other cases will inevitably break. sometimes it is possible to make something close to the original by adjusting constants and adding some hacks, and sometimes it isn't.

 

i mean, thank you for reporting, and i'm sorry. i may still find a way to make it work in the future, but for now i just don't know how to do it without turning the engine into freakin' mess nobody (including myself) will be able to understand. i'm not trying to dismiss your reports, just trying to explain why it may take alot of time to fix those things. thank you for spending your time telling me about the bugs!

Edited October 13, 2020 by ketmar

[ketmar]

great news everyone! with invaluable help from @Mr.Rocket we tracked the cause of graphics jittering, and fixed it! it was my desire to optimise things that need no optimisations. @Mr.Rocket thank you, man! you helped not only me, but all people with new NVidia drivers. expect a new build very-very soon. really soon this time! ;-)

Edited October 18, 2020 by ketmar

[Dagger]

Too cool...

 

[Mr.Rocket]

Hey np man, glad to help. ;)

[ketmar]

and here we go! now all NVidia owners will be able to enjoy The Best Doom Port On Our Planet again!

 

* applied *BSD compatibility patch from Cacodemon345 (thanks!)
* fixed "graphics jittering" issue on newest NVidia drivers (thanks alot, Mr.Rocket!)

[Mr.Rocket]

Hi, I don't think this has to do with our recent tests etc, but when I setup a multiplayer game and set to deathmatch, eg classic deathmatch or alt-death, deathmatch 1 or 2.

 It doesn't seem to go into deathmatch mode. Because when you spawn, you spawn in a single player spawn point instead of a deathmatch spawn point, also you spawn without keys. So, I'm guessing it's just not loading the deathmatch game mode, even though it says which deathmatch mode your in, in the console.

 

Also this must have just recently happened, because in 540818 the deathmatch mode does what it should, but in 550930 and up it doesn't.

I'm pretty sure this was happening before our recent tests.

 

p.s. I noticed it when I first started implementing it in the new launcher, then went in game and was like, well..no wonder heh.

 

 

Edited October 26, 2020 by Mr.Rocket

[ketmar]

@Mr.Rocket sorry for a long delay! the whole thing is very sensitive to the argument order. any small change may affect it. so, please, check if it really worked with some previous versions. and give me the exact command line. our fixes shouldn't break anything, but who knows, maybe it's really a new bug. ;-)

[Mr.Rocket]

-doom2 +MaxPlayers 2 +Deathmatch 2 +RespawnMonsters 0 +Fast 0 +Skill 4 +NoMonsters 1 +TimeLimit +noexit 0 +map MAP03

The above works just fine in 540818, goes into deathmatch mode, has all the keys, spawns in DM starts etc.. ~ even though the jitter is in this one.

 

The above does not work as it should in 550930, it says it's in deathmatch 1 or 2 in the console, but it isn't in-game, doesn't have all the keys, doesn't spawn in DM starts, spawns in single player starts..

 

The above does not work as it should in 551019, it says it's in deathmatch 1 or 2 in the console, but it isn't in-game, doesn't have all the keys, doesn't spawn in DM starts, spawns in single player starts..

 

Again, I'm pretty sure this was happening before the jitter fix.

 

 

Edited November 2, 2020 by Mr.Rocket

[ketmar]

4 hours ago, Mr.Rocket said:

The above works just fine in 540818, goes into deathmatch mode, has all the keys, spawns in DM starts etc.. ~ even though the jitter is in this one.

oh, yeah, it seems that i accidentaly it quite a long time ago! fixed, thank you!

 

i'll PM you a test build soon, so you will be able to properly test the launcher yet again. ;-)

 

p.s.: it worked with a dedicated server, so i never noticed that "combined" one is broken.

Edited November 2, 2020 by ketmar

[Mr.Rocket]

No rush man, take your time, l)

[Giomancer]

On 6/18/2020 at 10:39 AM, ketmar said:

there is still code to read nodes lumps, but it isn't even called

 

What! Ignore my node lumps, will you? shakes fist

xD

 

If I recall, original Vavoom would check if GL nodes existed upon loading a wad, and would build them if they did not. Why not go this route?

Edited November 10, 2020 by Giomancer

[ketmar]

4 hours ago, Giomancer said:

If I recall, original Vavoom would check if GL nodes existed upon loading a wad, and would build them if they did not. Why not go this route?

mostly because it has no practical sense. rebuilding nodes even for huge maps is fast, and if it takes more than several seconds, the engine will cache built nodes. internal builder is using floating point (as the rest of the engine), and there is no need to convert its output to fixed point and then back to FP again. the only reason to read external nodes is some BSP trickery, but such tricks will prolly won't work with k8vavoom anyway (and will hurt both stencil shadows, and lightmap tracer).

 

i.e. maps with BSP tricks will be broken anyway, and all other maps will benefit from using internal builder. cache system will take care of long startup times for slower CPUs (yet even my old i3 is fast enough to almost never hit the cache).

 

the same is true for blockmaps. it also helped me to find a bug in blockmap tracer code (inherited from ZDoom), that was sitting there for a decade, which is good for both engines, i believe.

 

and, of coruse, i don't have to maintain node reading/conversion code anymore. which is good, because i am teh old, fat and lazy bastard.

[Giomancer]

Well, I suppose that's one less thing for me to worry about when mapping, then!

[ketmar]

1 hour ago, Giomancer said:

Well, I suppose that's one less thing for me to worry about when mapping, then!

there is one thing you should know, tho: original (vanilla) code has a subtle... let's call it a "bug" in "point in subsector" code: if a thing is placed exactly on a linedef, vanilla may put it into back sector, and "normal" BSP code will choose front sector instead. k8vavoom tries to emulate this, but mostly for axis-aligned linedefs (i.e. vertical or horizontal). just avoid putting things exactly on linedefs (one unit away is enough). for non-axis-aligned linedefs, move it sligthly more (two-three units), because of rounding in vanilla.

 

tl;dr: always put things two-three units away from linedefs. this way everything will work the same way in every sourceport.

Edited November 13, 2020 by ketmar

[Mr.Rocket]

 In layman's terms, k8vavoom has some really impressive shadows such as a Doom3 type of hard shadowing and sort of Quake smooth shadowing. Not only the common radius shadow that we all see in most source ports, which is of course in k8vavoom too. That said, map geometry likely plays a roll in constructing such things specifically, on top of said shadow lighting, and likely wouldn't be easy to keep track of, for the engine or the developer.

Edited November 16, 2020 by Mr.Rocket

[ketmar]

@Mr.Rocket yeah, map geometry matters too. yet for lighting, it is more about light radius, and number of visible big lights. like, several huge outdoor light sources to emulate sunlight will slow D3-style shadows to the crawl (there's no way around it), and if that light is somehow flickering or pulsing, it will do the same for Q-style lighting (because such lights cannot be statically precalculated). i'm planning to introduce directional light sources to allow much better and faster outdoor sunlight emulation, tho.

 

but what i was talking about is the bug we had in one of Gunrock's SS:Remastered maps: the turret that was shooting way to high in k8vavoom. with Graf's help, i found the cause: the turrent was standing right on a linedef. front linedef sector was higher than the back sector. Vanilla (and GZDoom, because it emulates Vanilla) put the turret in the back sector, but k8vavoom put it into front one. so in k8vavoom the turret was put higher (due do higher front sector height). i never knew about that Vanilla quirk until Graf pointed me to it.

 

to fully emulate it, GZDoom, for example, keeps original vanilla nodes (not GL ones, those made for vanilla .exe), only to use them in several places where it matters. yet k8vavoom totally ignores vanilla nodes (they aren't useful for GL ports at all), and i didn't felt like keeping them around for exact emulation. so i added a small hack to emulate this quirk, but it works better for axis-aligned linedefs, and somewhat unstable for others (i prolly should rework it, but...).

 

this matters, because some Heretic maps (or Hexen, i don't exactly remember) have such things placed on linedefs, and spawning them in the wrong sector will make unreachable items, stuck monsters, and so on. nothing really fatal, but still...

 

 

i hope that wall of text makes some sense. ;-)

 

p.s.: putting light sources too close to the walls/flats will make the light disappear too. k8vavoom tries to "unstuck" such lights, but it is better to imagine light sources as spheres with 4-units radius, and place them accordingly.

Edited November 19, 2020 by ketmar

[ketmar]

also, k8vavoom is not dead. no wai! ;-) a new build is just around the corner. nothing really ground-breaking, mostly small bugfixes here and there. but alot of research work is happening behind the scenes. it's not the time to announce anything, but the project is alive and well, and i hope that my research work will eventually land into k8vavoom, bringing you even more half-finished buggy features you can complain about! ;-)

Edited November 21, 2020 by ketmar

[Remilia Scarlet]

Is there a proper place to report bugs, or should I just post things here in the forums for now?

I noticed that two options in the Advanced Rendering Options menu aren't getting saved for me: "Shadow Check" and "Optimise Shadow Flats".

[ketmar]

29 minutes ago, Remilia Scarlet said:

Is there a proper place to report bugs, or should I just post things here in the forums for now?

just write it right here, this is Teh Official Place for now. ;-)

 

29 minutes ago, Remilia Scarlet said:

I noticed that two options in the Advanced Rendering Options menu aren't getting saved for me: "Shadow Check" and "Optimise Shadow Flats".

the first one does nothing at all, i just forgot to remove it. and the second one is fixed. thank you!

[Remilia Scarlet]

13 minutes ago, ketmar said:

the first one does nothing at all, i just forgot to remove it. and the second one is fixed. thank you!

WOO!  Thank ya.  Rebuilding from git as I type ^_^

Also, random shot of me playing around in the engine 'cause I'm just fangirling all over the place over the Doom 3-style lighting at the moment: