ZDoom

Polymost was scheduled to be replaced more than 10 years ago, it's just too bad that the replacement never got sufficiently polished...

So this will forever require workarounds in order to "kinda work" then?

Sounds like the curse of Polymost, doomed to never be fully modernized.

This effect is highly dependent on how the screen is set up and what depth buffer format gets used, in short : Behavior is pretty much undefined, sometimes you are lucky and sometimes you are not. But let TerminX's actions and remarks be a clear warning: He had to fudge around with it multiple times and his commit messages often contain words like "it probably still sucks". Meaning that you can make a change that fixes one map but exposes problems on another. But with the render algorithm at play here it cannot really be fixed - the code is way too complicated for a simple catch-all solution.

Graf Zahl wrote:I really don't get it why, even after so many years, nobody has ever tried to fix the depth buffer problem, the values being stored in there are abysmally inappropriate for the task and yet, even modern hardware slavishly sticks to what's thoroughly broken.

That's probably because "it just works" .

No, like, really, I don't know what eduke does here, but it must do something since I've never managed to experience this in it.

All in good time, thank you for explaining the processes to me as I find it all very fascinating

I made a few mistakes in that branch, transitioning parts too early, before they were fully operational. The plan is still to get away from the makeshift backend I initially wrote for Polymost because that one is not extensible at all, but it needs to be done more carefully. Right now I just try to get the features in I need for fixing the sky rendering. For that I need the texture manager working at least.

For what it's worth, the backend_unification branch in its current state while far from perfect, was rather playable; at least for Duke 3D which is what I mainly tested on it. I'm glad all the efforts there weren't in vain though and most/all but the renderer parts were able to be unified

The way Polymost mangles its geometry will always present a major issue, mainly because the code is totally incomprehensible with all that fixed point voodoo math.

Regarding Icecolduke, I'll certainly take a look at his code - but the main issue is that it's Vulkan-DX12 only which for retro games is too high a target.
For now I am trying to piece the unified backend back together without breaking the renderer like last time. At least I was able to get back the improvements to the sound system, like supporting music playlists, but unfortunately some of the earliest work in that branch, i.e. the palette translation management has some serious issues which block merging most of the rest of the branch. So for now I'm trying to merge in the non-renderer parts just to reduce the working surface for later. TBH, if I can get the ZScript compiler back in it'd be enough to start work on porting the menus and status bars to a more modern backing implementation.
The renderer refactoring will definitely have to wait until after the next release.

I guess these issues will be something that gets sorted throughout the passage of time. Will you be able to make Polymost into what it needs to be, or is the idea to just get it workable on the unified backend and write something new that gets these things right from the start?

My own hypothesis is that the community is smaller and they've had people come and go from it. Icecoldduke has done/is doing some preliminary work on converting Polymer D3D12/Vulkan here, but this is also the 4-5th time he's started some kind of renderer work for EDuke32 and there's considerable doubt that he'll be available for the long haul to see this effort through as well.

The problem here is insufficent resolution of the depth buffer combined with a poor approach to render sprites - and the higher the resolution gets, the lower the depth resolution in the distance will become . To do it right it would have to separate flat, wall and face sprites - rendering non-translucent flat and wall sprites in the solid geometry pass and then the face sprites along with translucent walls without depth write in strictly sorted order, like GZDoom does. But since Polymost has nothing that matches sane solid geometry it's not easy to pull off.

I really don't get it why, even after so many years, nobody has ever tried to fix the depth buffer problem, the values being stored in there are abysmally inappropriate for the task and yet, even modern hardware slavishly sticks to what's thoroughly broken.

Thanks for taking a look. I can confirm it's much better now and I can't see that health vial, but I do still see the outline of the clock. It seems to be exasperated by how high your resolution is. I play at 4K and when I switch to window mode or scale down in some way, it's not visible.

At least the cause and a solution is known. Great to also see some recent action as well as it's been a bit quiet in recent times, I hope all's well in your world

Strange. I think this is related to some ill-advised hackery the renderer does to avoid z-fighting. EDuke did some tweaks to this code in 2017 which upon verification did some really bad stuff - another map where sprites bled through other things is the Hollywood sign in World Tour. I partially reverted the tweaks an it seems to behave much better now.
Of course this isn't a fix - the entire implementation of the sprite renderer is quite a bit broken right now, but only a complete rewrite may be able to fix that...

Just wanted to add an update that at least for me, this is hardware-specific. This does not happen on my work laptop with Intel graphics, only my home PC with an NVIDIA GeForce GTX 970. Just updated to the newest drivers again and same issue.

markanini wrote:Since lowskill didn't provide a save file from that spot, here's mine: https://www.dropbox.com/transfer/AAAAAL ... GZ4F235pvo

Oh I did, privately .

Since lowskill didn't provide a save file from that spot, here's mine: https://www.dropbox.com/transfer/AAAAAL ... GZ4F235pvo