ZDoom

Yes. Confirmed again.

Would have said something sooner, but I screwed up something the first time I edited the file somewhere and ended up with an error on launch. Second time it worked and textures are visible again.

Lycanite wrote:So from experimenting I've found that the problem is with gl_ClipDistance[2]
Sprites are showing again when changing

Code: Select all

gl_ClipDistance[2] = uClipSplit.y - worldcoord.y;

To

Code: Select all

gl_ClipDistance[2] = 1;

Thanks. I'll have a look later today how to address this.

is Any way I can fix the sprites it shows the weapons but not the enemies im new to this stuff and I don't know how to fix this.

Turns out setting part of or all of those values to 1, at a glance fixes things but when further testing 3D floors and sprites don't get there ordering right where you end up seeing walls through 3D floors and some sprites are hidden be certain walls, etc, I'm guessing this is just the clipping being all off or something.

cybersoldier32 wrote:is Any way I can fix the sprites it shows the weapons but not the enemies im new to this stuff and I don't know how to fix this.

I've got a compiled version of GZDoom modern that I'm using now with clipping disabled for the latest AMD drivers but I don't want to redistribute a 'rouge' build of GZDoom, but you can use:
-glversion 3
as a launch argument in the meantime and it should work, though this will probably disable some advanced features so is only temporary until either a fix is found for GZDoom or AMD sort their drivers out.

I still have no idea what happens here. For some reason a negative value must end up in that clip plane, but it must be some driver inconsistency, otherwise other hardware would also be affected.

I've submitted a bug report as have some others to AMD, all was fine until 18.7.1, I've never had issues like this before and have been using AMD for years so yeah definitely something funky with the recent drivers, there are other issues too such as constant lag unless HDCP is disabled on all monitors.

I've submitted a bug report as have some others to AMD, all was fine until 18.7.1, I've never had issues like this before and have been using AMD for years so yeah definitely something funky with the recent drivers, there are other issues too such as constant lag unless HDCP is disabled on all monitors.

Lycanite wrote:I've submitted a bug report as have some others to AMD, all was fine until 18.7.1, I've never had issues like this before and have been using AMD for years so yeah definitely something funky with the recent drivers, there are other issues too such as constant lag unless HDCP is disabled on all monitors.

So, how do you turn off HDCP?

I noticed on Doom2 MAP01 that, when gl_ClipDistance[2] was set to 0, the imps in the outside area still got their lower bodies clipped & the shotgun was also clipped. I figured it was because their worldpos.y was negative, when meant that uClipSplit was being set to {0,0}. That seems impossible, since it's initialised to {-1000000, 1000000} in ClearClipSplit. That made me think that the uniform wasn't being updated correctly, and so I compiled a debug build & checked what index we were getting back from glGetUniformLocation('uClipSplit"): it's -1 (not present), so the new GLSL compile is... optimising it out.

This is related to the OpenGL bug where no Sprites are being drawn.

It is specified on the pinned topic that its an ATI driver bug.

Let me point you on the right direction:
- This bug affects Sprites on Software Rendering, Softpoly and OpenGL. Software Rendering behavior is intermittent. It shows sprites If you are doing absolutely -nothing-. As soon as the party starts happening, sprites disappear, only to reappear again.
- This behavior happens when there is a decent amount of sprites on screen, meaning that the amount of sprites in view may, or may not, increase the instability.
- Although this happens on 99% of the sprites, both SW Rendering and Softpoly Rendering, weapon sprites are always shown as they are supposed to.

If the GZdoom's SW Rendering method is solely done by the CPU, which matches the Doom's original rendering design, instead of the GPU then this erratic sprite behavior shouldn't happen in the first place.

Even though this behavior is present using any IWad by itself, run GZdoom with "Brutal Doom 3.0: Black Edition" so you can test it out under the same circumstances I just did.

I just noticed this today when moving to another machine(Old sony laptop from 2011 that has ATI Video) using the latest of GZdoom. I downloaded the last version of Zdoom and it works just fine.

So in essence, using the OpenGL Renderer is bork until AMD patches this. Otherwise we have to rollback drivers or deal with the vanilla Doom render?

Pretty much that. And since this is apparently some shader miscompilation of perfectly valid code it's hard to provide an engine side fix for it.

God damn that sucks. Let's hope AMD will do us a solid and fix this, but I'm not so sure how they feel about fixing problems involving old games.

Sadly I updated AMD drivers to 18.9.1 and they still haven't fixed it. On the upside they did finally fix some other big issues so hopefully they'll see to this problem next.