[0.6.0-452-gfc466849ce] Lighting isn't diminishing properly

[mjr4077au]

@lowskill, can I please ask you to share your build? I'm doubtful there's a distance as I've tested on Linux and Windows and the lighting still isn't finishing as it did before for me. Won't be able to test for about 10 hours though

[sinisterseed]

@lowskill, can I please ask you to share your build? I'm doubtful there's a distance as I've tested on Linux and Windows and the lighting still isn't finishing as it did before for me. Won't be able to test for about 10 hours though

Of course - https://drive.google.com/file/d/1OiikiX ... sp=sharing

[mjr4077au]

For some reason I can't run your copy as per the attached. Not sure why.

I've built a copy on the work laptop to test another GPU and its the same as my main PC in that light is diminishing, but it's not 1:1 with 0.6.0 and earlier. If it's no longer meant to be 1:1, it can be closed off but the original algorithm should be available for those who want it.

[Graf Zahl]

I cannot see a signficant difference. It may be that the factors are slightly off now but it's never significant enough to notice the difference. It wasn't 100% faithful anyway, true palette emulation is quite a bit darker in some colors.

[sinisterseed]

For some reason I can't run your copy as per the attached. Not sure why.

I've built a copy on the work laptop to test another GPU and its the same as my main PC in that light is diminishing, but it's not 1:1 with 0.6.0 and earlier. If it's no longer meant to be 1:1, it can be closed off but the original algorithm should be available for those who want it.

That's interesting, so it basically does not detect your game files. I wonder why, I'm having no such issue here.

It's as if the game detector broke somehow.

[mjr4077au]

For some reason I can't run your copy as per the attached. Not sure why.

I've built a copy on the work laptop to test another GPU and its the same as my main PC in that light is diminishing, but it's not 1:1 with 0.6.0 and earlier. If it's no longer meant to be 1:1, it can be closed off but the original algorithm should be available for those who want it.

That's interesting, so it basically does not detect your game files. I wonder why, I'm having no such issue here.

It's as if the game detector broke somehow.

Yeah not sure what's happened there... It's all good though.

I cannot see a signficant difference. It may be that the factors are slightly off now but it's never significant enough to notice the difference. It wasn't 100% faithful anyway, true palette emulation is quite a bit darker in some colors.

It's significant enough that I made a bug report for it though . I tested the equiv lighting mode in GZDoom's master that you just got going where I have large, dark areas and assuming it's the same algorithm, it's diminishing eventually but just further away from the player's view port.

With palette emulation on, the level of brightness experienced would be acceptable, but without it it's just too bright in my opinion.

[Graf Zahl]

In GZDoom it's not really the same. I had to tweak the light fading considerably to make it an acceptable setting for Doom - and since Doom doesn't have the separate 'visibility' parameter I also had to derive the visibility from the light level.

For now I won't touch this code, though. Since the general formular now works in the backend I'm going to do the transition to that as the next thing. Once the transition is done we should see that everything is correct again. I'm going to need your help for that because for me it's close enough to not being able to see the difference.

Be advised that this will mean that the palette emulation has to be temporarily disabled - the backend cannot do it and I only can reimplement it when the rest is working.

[mjr4077au]

I'll be happy to help with that and whatever else I can for the project . I play without palette emulation for the most part so I won't be bothered if that's disabled, I just test it from time to time as part of testing what I can to make sure things are still operable with all the backend changes.

Will the palette emulation just become a tonemap like the other tonemaps in GZDoom or are they different things? I assume there's a difference since the palette emulation turns off anisotrophy and texture filtering whereas the tonemaps don't.

[Graf Zahl]

The palette emulation here is not a tonemap, it truly works on the palette level in the shader. GZDoom never had such a mode so the backend cannot do it.

Obviously doing color lookup like that comes with a few gotchas - this mode will never be able to show dynamic lights because once the palette shade has been applied the color precision is lost forever. There's also the issue that fog is baked into the shade maps which severely limits what can be done with this.

My only reason to actually support this mode was to have it for comparing the visuals, if that's what I cared about I would have stopped the moment I found out what makes EDuke's renderer stutter like crazy when VSync is on. The true color renderer was what I really was after.

[mjr4077au]

Thanks for explaining to me . I think it's good to have it also as a lot of people do like it so it can help you target a wider audience.

Regarding the vsync issues in EDuke32, I found that calling glFinish() after SDL_GL_SwapWindow() 'fixed' the stuttering at the expense of some fps, but it feels very much like a workaround for something Polymost is just doing wrong.

[Graf Zahl]

It's not Polymost - it's that they use an outdated OpenGL feature and have their code designed in a way that makes it hard to change. Remember: The Polymost core is totally unmodernized code written by Ken Silverman some 15-17 years ago for hardware like a Geforce 4 or a Radeon 9xxx. But even on this old hardware the combined texture/sampler object was a source of performance issues.

Back in OpenGL 3.2 a new concept of "Texture samplers" as separate state objects was introduced, because this is how hardware really works. Before that the sampler state was part of the texture. This all isn't really an issue as long as the sampler state remains immutable - but will take a massive performance hit if you constantly change this sampler state.
In older GZDoom's this led to duplicated textures just to manage the different sampler states for them.
And Polymost constantly changes these settings around.
Once I managed to clean up the texture management in Polymost to transition to texture sampler objects all the performance issues just went away completely.

[sinisterseed]

Basically, EDuke32 has major issues because, for some reason, the maintainers also have a desire to keep it compatible with as many systems as inhumanly possible, even the ones that are long obsolete. And naturally, when you do that, your software will never be optimized for any platform. They also seem to work around most issues, as in, constantly treating the symptoms rather than the root cause.

At any rate, at what stage is the backend migration actually? To me it looks like most things have been fully transitioned and only a few things remain, mostly.

[mjr4077au]

I don't necessarily think they're deliberately keeping it at OpenGL 1.1 by choice, more so that they don't have anyone who can work on the rendering side of things. They did try to get rid of Polymost with Polymer but plagman left the scene so that put it into maintenance mode.

icecoldduke was off to the races with a DX12, then Vulkan renderer here but with no work for 13 days, I can only assume stopped working on it like he has with his past efforts. That is a shame because I tested his code and its quite usable given the short amount of time that's been placed into it.

[sinisterseed]

I don't necessarily think they're deliberately keeping it at OpenGL 1.1 by choice, more so that they don't have anyone who can work on the rendering side of things. They did try to get rid of Polymost with Polymer but plagman left the scene so that put it into maintenance mode.

icecoldduke was off to the races with a DX12, then Vulkan renderer here but with no work for 13 days, I can only assume stopped working on it like he has with his past efforts. That is a shame because I tested his code and its quite usable given the short amount of time that's been placed into it.

It actually isn't from what I can gather. icecoldduke essentially tossed DX12/Vulkan into the existing flawed foundation, which means that the work he's done so far doesn't have much use.

It is sadly more of a proof of concept kind of deal rather than something with actual, real world use. It can be used for a thing or two and maybe as a reference, but I think that's pretty much all.

[Graf Zahl]

At any rate, at what stage is the backend migration actually? To me it looks like most things have been fully transitioned and only a few things remain, mostly.

I am currently writing the layer that translates my Polymost render lists into backend draw calls, i.e. the most crucial thing. Once this works to some degree and I can start phasing out my old GL-only backend the worst is done and it's time to fix it up for a new release, which then would be 1.0.

Regarding EDuke, the problem is not trying to support as many systems as inhumanly possible, I think the problem is that nobody is willing to dive in and do a refactor of the rendering code. Most of Polymost is so old that the hardware it originally targeted no longer exists. It's from the time when the first GZDoom version came out, but I have basically rewritten the entire backend since then, there's hardly any code left of 0.9.0 that directly deals with OpenGL API access. When comparing Polymost of JFDuke with the current version you can see that the texture management is mostly still the same code as 15 years ago.