[0.5.0]+ Duke3D, E2L1 secrets revealed due to Z-fighting?

[mjr4077au]

Bug post at Duke4.net is here.

Now, this happens in EDuke32 and RedNukem, but in a worse way than Raze. In the upstream ports, the tile on the wall is consistently chopped whereas in Raze, the tile renders correctly the further back from it you move.

I'm calling it a Z-fighting issue becase in the upstream ports, this issue does not occur in the software renderer. I assume the software renderer is doing some kind of Ken-ism to make it work right in similar vein to how Z-fighting was not an issue in WinQuake, etc.

E2L1_ZFighting.jpg

[Graf Zahl]

Yeah, the big problem with Build ports is that none of the renderers is working correctly - some stuff is only correct in the software renderer, other only in Polymost and yet other only in Polymer. And there's no good documentation of all the hacks that have been used over the years by modders.

Here also lies the biggest problem for me: I do not know all the hacks and minute details of Build, so I do not really know what to look out for when eventually starting work on a better renderer

It's a real shame that Polymer was only interested in getting lighting effects to work instead of first providing a stable foundation - or we wouldn't be here right now.

In any case, I think this is the same issue as this one:

viewtopic.php?f=340&t=67516

[Phredreeke]

From my experience this particular sign goes back and forth between working and not working between revisions.

[mjr4077au]

From my experience this particular sign goes back and forth between working and not working between revisions.

Any idea what a known good revision would be?

[Graf Zahl]

It's rather pointless. Unless the rendering of attached wall sprites isn't fundamentally changed you'll never be able to fix it because it'd always depend on some uncontrollable factors.

The way this really needs to be done is like decals in GZDoom, i.e. attach the sprite to the wall (all Build does is trying to find the nearest wall each frame) and render it as an overlay and not as a sprite with a special angle. The decals work properly because the code that processes them knows about the underlying wall and doesn't position them independently.

In Build the sprite holds no reference to the wall. It's like so many things in Build - a sloppy implementation that just happened to work with software rendering. But I've seen some weirdness with floor and wall sprites when being used with moving walls. Glitchfest galore...

[sinisterseed]

Oh wow, now that looks pretty crappy, I'm gonna have to see this for myself when I get home.

But is always visible now, for some reason, or does it also disappear from certain angles/distance? Is it also flickering back and forth?

[mjr4077au]

Oh wow, now that looks pretty crappy, I'm gonna have to see this for myself when I get home.

But is always visible now, for some reason, or does it also disappear from certain angles/distance? Is it also flickering back and forth?

Disappears the further back you go or depending on the view angle. It's just completely broken in EDuke32 though, but works as expected in the software renderer. Polymer has flickering issues.

Even happens in older ports like JFDuke3D, which I compiled from jonof's github. Just one of those things with the renderer I guess.

[Phredreeke]

I was mixing up the ports in my head. BuildGDX renders the sign correctly.

[sinisterseed]

Aight, compiled a new build for today and yeah, it flickers in Raze, depending on both angle and distance, like other instances in the game.

The curious thing is that it doesn't flicker in EDuke32 (a build from Feb 12th) and RedNukem 1.0, it just renders incompletely, once the sign reaches the curve it stops. A typical example of something that was likely not done well from the beginning, but it just so happened to work correctly under Software, as it was the case with other things in Doom as well. If it happens in JF too, I am inclined to think that maybe it was inherited from it, but even so, it probably never displayed fully correct.

It is indeed hilarious and depressing that EDuke has so many renderers and none of them is actually doing everything right. Polymost is too basic and apart from rendering thing in GL it has nothing special, Polymer is incomplete and very poorly optimized, and Software doesn't count...

[Phredreeke]

Clearly what is really needed is a multithreaded version of the software renderer with DelphiDoom style perspective correction

[sinisterseed]

We need more power(TM) .

[Graf Zahl]

Clearly what is really needed is a multithreaded version of the software renderer with DelphiDoom style perspective correction

Nah. What we need here is to render these sprites like GZDoom renders decals. These are also attached to walls but don't glitch.

[Photonic]

But I've seen some weirdness with floor and wall sprites when being used with moving walls. Glitchfest galore...

Try a floor sprite elevator in multiplayer, even better use a non-pow2 height for the elevator.

[Phredreeke]

I finally realised why I thought I had it working in EDuke32 before. It's due to the maphack I had loaded at the time for the voxel pack. Specifically this line

Code: Select all

sprite 37 away1 // "Authorized Personnel" sign