k8vavoom: no good thing ever dies!

it is silk-smooth on my ancient nVidia GT720, so it's hard to say why. it may be AMD/Intel issue (both OpenGL drivers sux), or something windows-specific (i don't have windows at all; it works with Wine, but i don't know about real windows systems). shadowmaps/stencils are quite GPU-demanding too. you may try lightmaps, they are usually faster. the thing is also CPU-demanding too, but it shouldn't be the problem on Vanilla maps.

also, high resolutions are slow too (due to massive fillrates), so you may try to increase screen scale in resolution menu -- this will render in smaller resolution, and then upscale.

So I decided to give this port a try only to get this, I'm running Windows 11. Is this a know issue? 

I should note I did get it to work by setting compatibly to windows 8 as a temp solution but I just find this odd that it even happened, its usually older software that does this kind of stuff. 

Sorry for the double post but I noticed this issue when testing my map in this port, it looks like some UDMF options are not being respected

This box looks normal in Gzdoom, I guess this port doesn't like having a negative number for the texture scaling.

3 hours ago, Rexen² said:

So I decided to give this port a try only to get this, I'm running Windows 11. Is this a know issue?

yes. win11 is not officially supported, and will never be, sorry. it is better to fail early and verbosely than try to fight with that OS. i don't have windows at all, and win11 did some breaking changes i cannot test (and not really interested in testing, tbh). hence this error. windows support is a bonus, not a feature, k8vavoom primary platform is GNU/Linux. it just happened that i could use MXE to build windows binaries, and test them with Wine. i'm really sorry. dedicated windows developer may help here, but we have none so far.

2 hours ago, Rexen² said:

This box looks normal in Gzdoom, I guess this port doesn't like having a negative number for the texture scaling.

negative texture scale is GZDoom bug, stealthily promoted to a feature. (same bug as with negative 3d model scaling with HUD weapon models, for example). it is not documented in specs, and it is impossible to know how to implement it without diving into GZDoom code. it is quite hard to maintain bug-to-bug compatibility with GZDoom, sorry. [G]ZDoom devs never bothered to properly document all their hacks, so they (hacks, not devs ;-) could be implemented in other sourceports in compatible way. i'm doing my best, but sometimes it is quite hard: GZDoom code is a mess, and its rendering is completely different from k8vavoom, so implementing support for such bugs is not as simple as "look at GZDoom code and write the same in k8vavoom". sadly, i don't have enough time and resources to know both codebases. and without knowing GZDoom codebase, implementing things "as they should logically work on my opinion" leads to the thing we can see on your screenshot.

sorry for those wall of texts, i simply tried to explain my reasons for doing/not doing something. i want people to understand that in case somebody will want to argue. ;-) it is easier to argue when you have a full picture, and know what to address with your arguments. ;-)

Regarding Windows 11, that error message may some day go away, considering that the only release of Windows 11 is a pre-build, for testing/pre-release development version.

I have no issues running k8vavoom on Windows 10 Pro 64bit - 21H1. ;)

6 minutes ago, ketmar said:

yes. win11 is not officially supported, and will never be. it is better to fail early and verbosely than try to fight with that OS. i don't have windows at all, and win11 did some breaking changes i cannot test (and not really interested in testing, tbh). hence this error. windows support is a bonus, not a feature, k8vavoom primary platform is GNU/Linux. it just happened that i could use MXE to build windows binaries. i'm really sorry. dedicated windows developer may help here, but we have none so far.

 

negative texture scale is GZDoom bug, stealthily promoted to a feature. (same bug as with negative 3d model scaling with HUD weapon models, for example). it is not documented in specs, and it is impossible to know how to implement it without diving into GZDoom code. it is quite hard to maintain bug-to-bug compatibility with GZDoom, sorry. [G]ZDoom devs never bothered to properly document all their hacks, so they can be implemented in other sourceports in compatible way. i'm doing my best, but sometimes it is quite hard: GZDoom code is a mess, and its rendering is completely different from k8vavoom, so implementing support for such bugs is not as simple as "look at GZDoom code and write the same in k8vavoom". sadly, i don't have enough time and resources to know both codebases. and without knowing GZDoom codebase, implementing things "as they should logically work on my opinion" leads to the thing we can see on your screenshot.

 

 

sorry for those wall of texts, i simply tried to explain my reasons for doing/not doing something. i want people to understand that in case somebody will want to argue. ;-) it is easier to argue when you have a full picture, and know what to address with your arguments. ;-)

Okay that first part I understand, that 2nd part was not something I expected, I can see why they promoted to as a feature since in this case it was used to make the box look like it got tossed upside down and beats having to make a new texture.

1 minute ago, Mr.Rocket said:

Regarding Windows 11, that error message may some day go away, considering that the only release of Windows 11 is a pre-build, for testing/pre-release development version.

GZDoom 4.6.1 add support for checking to see if it was running on windows 11 (mainly for crash reports and logs) but then again that is GZDoom and that's just the debug end of things and already had support for windows 11.

note: the most important part is the last paragraph. everything else can be skipped, as it is just my usual ranting. ;-)

12 minutes ago, Rexen² said:

I can see why they promoted to as a feature

sadly, it was done in typical ZDoom way: without properly documenting it, even without mentioning it in specs. it should be done with additional "flip texture" UDMF property instead... it's one of many things ZDoom did and never described -- like improved ACS bytecode format, which isn't documented anywhere besides ZDoom ACC and ZDoom ACS VM sources.

i tried to support negative scales, but without proper documentation it is hit-or-miss: it works on some maps, and breaks on others. fixing one of them breaks another, because it is all just a guesswork. (actually, the whole UDMF scaling is very poorly documented; it is impossible to implement scaling with offsets, for example, using only ZDoom UDMF specs). sadly, GZDoom is "new vanilla", and people expecting other sourceports to be bug-to-bug compatible with GZDoom.

if they will ever properly document the thing, i'll implement it according to specs. you can give me a test map too, i will try to look what is going on here, and maybe will be able to workaround it. basically, if something doesn't work right, don't be afraid of throwing test maps at me. ;-)

24 minutes ago, Rexen² said:

GZDoom 4.6.1 add support for checking to see if it was running on windows 11 (mainly for crash reports and logs) but then again that is GZDoom and that's just the debug end of things and already had support for windows 11.

True, hopefully when Win11 shows errors messages about anything it will at least be pushed to their development team, that and at least ketmar knows now that (thanks to you) users running Win11 and k8vavoom may have some compatibility issues going on. Even though he has no means of fixing it, and since it runs fine on the latest Win10 anyway, it's likely an O/S issue which hopefully Microsoft will fix, if there's any report to get to them. Hopefully the error throws a red flag to them that IP with such and such Win11 specs encountered a problem while running such and such app. 

Curious if you like Windows 11 so far? I'll likely wait for the full version to come out.

@Mr.Rocket let's be fair here: it's not win11 fail, k8vavoom explicitly checks for win11, shows that message box, and shutdowns itself. ;-) sorry for not making that clear. it does something like this for nVidia RTX30xx GPUs too, for example (yet in this case it simply shows a warning in menus).

i may switch to warning later, when win11 will be officially released and field-tested for some time. but for now, it is better to fail early, i believe.

Well, I suppose a soft error is better than no error at all, heh.

Thing is, users on Win11 has to run in Win8 compatibility mode, while I'm running Win10 currently with all updates, with no issue at all. 

i simply know that warnings never work. ;-) people are running the software to use it (to play Doom in this case ;-), not to read all that shit software tries to throw at them. so most people see warnings as annoyance, and alot of people don't even read them. by making it a hard failure i did my best to get people's attention. i should definitely improve the wording in that messagebox, tho.

So currently the message is only there simply because it hasn't been tested enough to guarantee that the engine will indeed run on the O/S.

I suppose we'll just have to wait and see when there's enough Win11 users saying that it runs fine on the official Win11 build, right?

Though it will be hard for them to say that it does, when they currently have to run in Win8 compatibility mode.

5 minutes ago, Mr.Rocket said:

I suppose we'll just have to wait and see when there's enough Win11 users saying that it runs fine on the official Win11 build, right?

mostly this, yeah. the warning will prolly stay there, but i will lower it from "no wai, i'm dead!" to much less intrusive and non-fatal "we'll continue on your own risk" later.

You could have it say "Well, you would have to go an update to Windows 11, now I have to leave you with this damn message!", :D

To be honest, I'm running Windows 11 to test it and give feedback. Of course I'm also well aware things might break as a result but I did want to ask just in case it was a bug after all.  

32 minutes ago, Rexen² said:

but I did want to ask just in case it was a bug after all

yeah, it is always better to ask/report, in case it is a genuine bug. thank you for doing that!

On 7/27/2021 at 1:15 PM, ketmar said:

it is silk-smooth on my ancient nVidia GT720, so it's hard to say why. it may be AMD/Intel issue (both OpenGL drivers sux), or something windows-specific (i don't have windows at all; it works with Wine, but i don't know about real windows systems). shadowmaps/stencils are quite GPU-demanding too. you may try lightmaps, they are usually faster. the thing is also CPU-demanding too, but it shouldn't be the problem on Vanilla maps.

 

also, high resolutions are slow too (due to massive fillrates), so you may try to increase screen scale in resolution menu -- this will render in smaller resolution, and then upscale.

ah, ill try that, thanks!

19 hours ago, ketmar said:

@Mr.Rocket let's be fair here: it's not win11 fail, k8vavoom explicitly checks for win11, shows that message box, and shutdowns itself. ;-) sorry for not making that clear. it does something like this for nVidia RTX30xx GPUs too, for example (yet in this case it simply shows a warning in menus).

 

i may switch to warning later, when win11 will be officially released and field-tested for some time. but for now, it is better to fail early, i believe.

Why make it crash if it runs on Windows 11 or an RTX 30xx GPU ? Especially the latter, I've never heard of a game that runs on an RTX 20xx GPU but not a 30xx one.

7 hours ago, jeremieh said:

ah, ill try that, thanks!

what we really need is profiler subsystem. currently there is no way to see what causes lags. i am planning to implement profilers for almost 2 years, but... this is something that should be done at the start of the development, otherwise it becomes very boring task. i know how to do it, but it is so boring, that i am keep finding reasons to do it "later". ;-)

2 hours ago, inkoalawetrust said:

Why make it crash if it runs on Windows 11 or an RTX 30xx GPU ?

it doesn't crash on RTX, it merely shows a warning in video options menu. it is harmless and non-intrusive, just several lines of text, you don't even have to press "ok" in a message box or something. the whole RTX30xx fiasco is known to be problematic in several ways, so i prefer to warn the user about this.

as for win11 -- there is no win11 yet at all. i don't have it, i didn't tested it, and i am officially don't support windows betas. so i prefer to get "it crashes" instead of potentially strange and impossible to reproduce bug reports. next build will lower this to non-fatal message box for official win11 releases (betas won't be supported, tho). as we have zero windows developers, it is better to be safe than sorry.

...and some boring news: i decided to switch to DarkDoom lighting mode by default starting from the next build. i am currently playing with it to catch bugs and get used to it, and i must say that i like it more than the original fog-based lighting. it is also much closer to what most "non-Z*" map authors are targeting, so i think there is no reason to not make it default.

@Gwarl this may solve your problems with lighting too. original Vanilla lighting is non-linear and non-logariphmic, so fiddling with light level correction table cannot make things look "right". but the new mode is using the formula that is very close to vanilla instead of normal OpenGL fog.

I've been using a straightforward cubic interpolation (find attatched) for my personal use (intended to be used with r_darken 0), I was going to try and figure out how your menus worked and turn r_darkne into an int and put this in a menu and make a PR but cubic basically works well for me. k8vavoom really *is* too bright as it is with hardware, I promise.

dimlight.zip

I've found that with OTEX there are glitches in the fence textures if I set the texture filter to "Trilinear", but setting it to "Nearest" solves the problem.  Apologies if this is already known.  I usually set it to "Trilinear" in GZDoom and haven't had those glitches.  That said, having checked, I don't notice any tangible difference between "Trilinear" and "Nearest" in GZDoom, so I don't see this as a major issue other than from a "remembering not to choose the wrong setting" point of view.

In other news, I'm experimenting with creating an opening train based sequence using k8vavoom, drawing upon the test map with the working 3D platform and door.  My inspirations come mainly from the opening map in Heartland (which utilised Eternity Engine's portals, so a rather different method of implementation) and the monorail sequence at the start of Half-Life.  At present I'm just experimenting to see how well the system works, but it's "so far so good" and already I've got linked polyobjects working as they should.

My modification of BDLite is still progressing too, but I don't think I've done enough with it to justify a first public release yet, so far I've mainly come up with an expanded roster of weapons with extra weapons ported from Brutal Doom and Project Brutality (an axe, pistol, auto shotgun, railgun and flamethrower), trimmed down substantially from the originals to match DavidN's coding conventions for the other weapons.  So far all of the new/ported weapons have worked equally well in GZDoom and k8vavoom.  The BDLite imp melee attacks didn't fully work in k8vavoom initially but with just minor changes to the code I was able to fix that, and I haven't yet found any issues with other monsters.

10 hours ago, Gwarl said:

k8vavoom really *is* too bright as it is with hardware, I promise.

it won't be anymore starting with the next public build! ;-)

here's better screenshots, to see the difference.

original mode (Vavoom):

DarkDoom:

as you can see on the pictures, it is way more contrast, and dark areas are much darker. don't mind the brightess around the player: as in vanilla, the player emits some light (it doesn't in Vavoom mode, so walking pitch-black areas in DarkDoom is easier).

there is no way to emulate this with darkening tables (and that table isn't even usen in DarkDoom mode), because you have to change the light level based on the distance to the player. it is doable with VavoomC, of course, but it will be freakin' slow.

6 hours ago, ENEMY!!! said:

I've found that with OTEX there are glitches in the fence textures if I set the texture filter to "Trilinear", but setting it to "Nearest" solves the problem.  Apologies if this is already known.

i'd like to see screenshots and test map. i'm not really using any texture filtering, and it is somewhat... orphaned. there may be various bugs, yeah.

6 hours ago, ENEMY!!! said:

In other news, I'm experimenting with creating an opening train based sequence using k8vavoom, drawing upon the test map with the working 3D platform and door.

yay! Half-Doom intro sequence? ;-) great. the more people will use 3d pobjs, the better. i'm sure that the implementation has alot of small bugs, and documentation is far from good, so we need people to really use this to make it rock-solid. or at least not very fragile. ;-)

6 hours ago, ENEMY!!! said:

My modification of BDLite is still progressing too

yay #2! i remember about bouncing bug, btw. but it's not an easy fix (i don't really understand bouncing code yet), and i'm usually working with one engine subsystem before switching to another. currently it is graphics effects, but i will switch to physics later.

6 hours ago, ENEMY!!! said:

The BDLite imp melee attacks didn't fully work in k8vavoom initially but with just minor changes to the code I was able to fix that

i'd like to know what wasn't working, and how you fixed it. compatibility with DECORATE mods is very important (that's why we have DECORATE support after all! ;-), and if it's not a BDLite bug, then i have to fix it on my side.

8 hours ago, ketmar said:

there is no way to emulate this with darkening tables (and that table isn't even usen in DarkDoom mode), because you have to change the light level based on the distance to the player. it is doable with VavoomC, of course, but it will be freakin' slow.

Turning the player into a light source does the trick, more or less

5 minutes ago, Gwarl said:

Turning the player into a light source does the trick, more or less

it doesn't solve light falloff, tho (vanilla formula for this is quite weird). also, vanilla "player lighting" is strictly depth-based, you cannot emulate this with a dynamic light source. i tried it (attaching dynlight to the player), but didn't liked the effect. yet DarkDoom mode is using almost the same lighting formula as vanilla, and we have that effect basically for free. anyway, old Vavoom mode won't go away, so people may choose the one they like more. but i changed the default, because i believe that DarkDoom is what most people are expecting/used to.

original Vavoom couldn't do it, because there is no way to implement vanilla lighting without shaders, and Vavoom had OpenGL1.1 shaderless renderpath. but i eliminated it long ago, so now there is no reason to not have more "authentic" lighting.

I'll give the new mode a try after I'm back from holidays

3 minutes ago, Gwarl said:

I'll give the new mode a try after I'm back from holidays

please, note that it is not in a public builds yet. sorry, i don't remember if you're on GNU/Linux, and if not, you can ask me for a test build in PM.

21 hours ago, ketmar said:

i'd like to see screenshots and test map. i'm not really using any texture filtering, and it is somewhat... orphaned. there may be various bugs, yeah.

Here's a test WAD:

test_texturefilter.zip

and a couple of screenshots, one with Nearest texture filtering enabled, one with Trilinear.  Anything other than "Nearest" or "Nearest Mipmap" produces this texture glitch, though interestingly it doesn't affect the lighting (I tested this by putting a dynamic light behind the fence).

For file size purposes I haven't bundled OTEX with the WAD.

Yes, the start of Half-Life quickly sprung to my mind when I decided to try and create a train sequence - I even ended up using that for some inspiration, especially regarding how to set up a fairly realistic-looking train interior.  I've got the train fully set up now, as well as some rails for it to move along, but tomorrow I'll get onto potentially the trickier part, getting it moving!

The problem with the BDLite imp was that its jump attacks in the Melee state weren't spawning the scratch sound or hurting the player, implying that for whatever reason the ImpMeleeAttack wasn't working:

    Melee:
        TROO E 1 A_FaceTarget
        TNT1 A 0 A_JumpIfCloser(50, "Scratch")
        TROT ACD 3
        TNT1 A 0 ThrustThingZ(0, 26, 0, 1)
        TNT1 A 0 A_FaceTarget
        TNT1 A 0 A_Recoil(-7)
        TROT EF 2
        TNT1 A 0 A_GiveInventory("IsJumping")
        TROT F 6
        TNT1 A 0 A_TakeInventory("IsJumping")
        TROT G 1 A_PlaySound("world/enemylanding")
        TROT G 2 A_SpawnProjectile("ImpMeleeAttack", 10, 0, 0, CMF_AIMDIRECTION, 0, AAPTR_NULL)
        TROT G 3
        goto See

I developed the following hack/workaround:

    Melee:
        TROO E 1 A_FaceTarget
        TNT1 A 0 A_JumpIfCloser(50, "Scratch")
        TROT ACD 3
        TNT1 A 0 ThrustThingZ(0, 26, 0, 1)
        TNT1 A 0 A_FaceTarget
        TNT1 A 0 A_Recoil(-7)
        TROT EF 2
        TNT1 A 0 A_GiveInventory("IsJumping")
        TROT F 6
        TNT1 A 0 A_TakeInventory("IsJumping")
        TROT G 1 A_PlaySound("world/enemylanding")
		TNT1 A 0 A_JumpIfCloser(64, "Melee2")
        TROT G 3
        goto See
	Melee2:
		TROO G 0 A_PlaySound("monsters/imp/melee")
        TROT G 2 A_SpawnProjectile("ImpMeleeAttack", 10) //, 0, 0, CMF_AIMDIRECTION, 0, AAPTR_NULL)
		goto See

3 hours ago, ENEMY!!! said:

Here's a test WAD:

very interesting, thank you! i can't even imagine where and how i fucked up so spectacularly. ;-)

3 hours ago, ENEMY!!! said:

Anything other than "Nearest" or "Nearest Mipmap" produces this texture glitch, though interestingly it doesn't affect the lighting

because the engine turns off texture filtering for shadowmaps: there is no reason to do filtering there, shadowmaps are holding only the distances, filtering won't create softer shadows, only worser.

3 hours ago, ENEMY!!! said:

For file size purposes I haven't bundled OTEX with the WAD.

no problems, of course i have otex, who doesn't? ;-) running with it as easy as adding "-mode otex" to command line (that's why i wrote support for modes long time ago! ;-).

3 hours ago, ENEMY!!! said:

The problem with the BDLite imp was that its jump attacks in the Melee state weren't spawning the scratch sound or hurting the player, implying that for whatever reason the ImpMeleeAttack wasn't working:

that code looks... strange. is it hard to extract *ONLY* imp from BDLite, so i could take a closer look? i mean, if it is not very hard, and you have some time, please, do it for me. but if it's time-consuming or something, then skip it, i will try to do it myself later (it will take much more time, tho, but as the hack works for you now, there's no time pressure, i guess ;-).