Dege wrote on 2025-04-22, 07:12:

It's because of this (at least I guess): F.E.A.R - Two remaining issues (well three) […]
Show full quote

Cambid wrote on 2025-04-21, 11:59:

Yes the glass can be fixed by actually fixing the shader (though CEnshine on custom edition or straight up hex editing the fx.bin on the retail version to use the correct sampler type). It's just that Dgvoodoo used to account for the stock shader being wrong but now doesn't. Not really a big deal though.

It's because of this (at least I guess):
F.E.A.R - Two remaining issues (well three)

I changed the mismatching sampler behavior for the sake of FEAR, and to match the native D3D9 driver implementations (I looked at various vendors). And that fix went into v2.8.

Btw, are there other problems with dgVodoo besides the indicator and this sampler-mismatch thing?
Frankly, I'm getting lost in this Halo shader-mess. I don't even understand why there is no only 1 fix for the game, containing the fixed shader binaries with the modified sampler types (independently on D3D9 implementations). Maybe I should have made a patch for it myself.
Also, I suppose the game appeared correctly with the contemporary GPU it was written for, so if I knew what that hw was (XBox ?), I could put back the old sampler-mismatch implementation for one/some of the virtual cards.

Geforce 3 on Xbox
Geforce FX/Radeon 9600+ on PC

Dege wrote on 2025-04-29, 11:02:

Cambid wrote on 2025-04-27, 20:12:

Yeah dunno what the deal is with the old gpu but the z-fighting significantly less than any of the modern implementations. The game has always had various issues with d3d9 implementations. I remember probably 10 years ago, glass reflections would flicker like crazy on AMD.

My only guess is the lightstrip polygons are not exactly coplanar with walls/ceils, and old hw with vertex shader 1.x/2.x support didn't have full IEEE-752 compliant floating point support unlike modern hw with at least sm4.x support. So, old hw must have produced larger precision errors and due to that, z-fighting was mostly avoided. And top of that, the game was played at lower resolution where the z-precision errors less likely appear, especially with triangle interpolators with larger imprecision compared to modern hw.

But it's only a speculation. TBH, I don't know what to do with this phenomenon.

Just an FYI I worked out a fix in-engine for the z-fighting which is in the latest chimera build. Increasing the frustum near plane distance very slightly when drawing those shaders did the trick.

Thanks! It was really ugly 😁

I'm more and more convinced this is a dgVoodoo bug as I haven't been able to reproduce it with dxvk or native d3d9. These small black rectangles occasionally show up on various textures on level geo throughout the game. Not really sure exactly how to reproduce consistently apart from play a bit and keep an eye out for when they show up.

the original game did that on hardware of the time, its a game bug.

So what should be the ideal settings for Halo CE on PC with dgvoodoo? Geforce FX5700 with D3D11 Output API? Is dgvoodoo even needed at all at present? the native d3d9 mode seemed to run just fine with the latest Chimera + CEnshine. I also get Seg faults when I press Esc when loading into a level, unsure if this is a Chimera bug or a some kind of gfx api bug.

The new combination is lastest Chimera+Restored (for Combat Evolved or Custom Edition) Maps, so you get ~XBOX rendering
*https://github.com/SnowyMouse/chimera
*https://drive.google.com/file/d/12xmwEpjBwuxE … m1tALM3Mmu/view (for Custom Edition)
No more need of CEnshine (of course you can use DSOAL -> https://github.com/kcat/dsoal to get EAX working)

About dgVoodoo2: no need to enforce a particular GPU/API but dgVoodoo2 itself is still needed.

New release of the (sinlge+multi) maps for the Custom Edition: https://cdn.discordapp.com/attachments/631949 … 48429987823b203&

Just use it with the lastest Chimera ( https://github.com/SnowyMouse/chimera/releases) and you're good to go.

This issue with the border color texture address mode on samplers with a A8L8 texture is also applicable to dgvoodoo: https://github.com/doitsujin/dxvk/issues/5388

Squall Leonhart wrote on 2025-07-28, 17:34:

the original game did that on hardware of the time, its a game bug.

No it's not. No other d3d implementation does this. It seems to be an issue specific to the d3d11 output API with AMD cards as I haven't seen it on my old intel iGPU. It does it with every old dgvoodoo version I've tried as well.

Cambid wrote on 2025-12-18, 14:18:

This issue with the border color texture address mode on samplers with a A8L8 texture is also applicable to dgvoodoo: https://github.com/doitsujin/dxvk/issues/5388

Squall Leonhart wrote on 2025-07-28, 17:34:

the original game did that on hardware of the time, its a game bug.

No it's not. No other d3d implementation does this. It seems to be an issue specific to the d3d11 output API with AMD cards as I haven't seen it on my old intel iGPU. It does it with every old dgvoodoo version I've tried as well.

my FX 5900XT running the game natively says otherwise.

Cambid wrote on 2025-12-18, 14:18:

No it's not. No other d3d implementation does this. It seems to be an issue specific to the d3d11 output API with AMD cards as I haven't seen it on my old intel iGPU. It does it with every old dgvoodoo version I've tried as well.

I had a look into it earlier and I could reproduce it both with my NV 1060 and an AMD R7360 natively.
Though dgVoodoo still seemed worse, but I couldn't find a bug in mapping the z-values and the bias (according to the DX9 specs).

Cambid wrote on 2025-12-18, 14:18:

This issue with the border color texture address mode on samplers with a A8L8 texture is also applicable to dgvoodoo: https://github.com/doitsujin/dxvk/issues/5388

TBH, I don't understand the problem. with A8L8 there is a component mapping
R -> L
G -> L
B -> L
A -> A

which should be applied to the bordercolor as well. So, when defining the bordercolor only the R and A components count in the D3DCOLOR parameter, G and B is ignored (dgvoodoo probably still not ignore them, I might change it).
(I didn't do testings)

Dege wrote on 2026-01-02, 10:46:

I had a look into it earlier and I could reproduce it both with my NV 1060 and an AMD R7360 natively.
Though dgVoodoo still seemed worse, but I couldn't find a bug in mapping the z-values and the bias (according to the DX9 specs).

I'm not sure we're talking about the same thing here. I'm refering to this random texture corruption that happens sporatically. These random black rectangles that are not part of the bitmap that show up on some mip levels.

Video example:
https://youtu.be/6_iG7frnkKc

The border colour issue is a strange one on Dgvoodoo because sometimes it works correctly and sometimes it doesn't, so I'm not really sure whats going on there.

I already understand that theres not much that can be done regarding the z-fighting issue.

Those black rectangles have ALWAYS occured.

The artifact in your image would be the blue pillars of light that show up into the sky.

Cambid wrote on Today, 10:58:

I'm not sure we're talking about the same thing here. I'm refering to this random texture corruption that happens sporatically. […]
Show full quote

Dege wrote on 2026-01-02, 10:46:

I had a look into it earlier and I could reproduce it both with my NV 1060 and an AMD R7360 natively.
Though dgVoodoo still seemed worse, but I couldn't find a bug in mapping the z-values and the bias (according to the DX9 specs).

I'm not sure we're talking about the same thing here. I'm refering to this random texture corruption that happens sporatically. These random black rectangles that are not part of the bitmap that show up on some mip levels.

The attachment vlcsnap-2026-01-11-18h47m36s758.png is no longer available

Video example:
https://youtu.be/6_iG7frnkKc

The border colour issue is a strange one on Dgvoodoo because sometimes it works correctly and sometimes it doesn't, so I'm not really sure whats going on there.

I already understand that theres not much that can be done regarding the z-fighting issue.

Ok, I see.
Do you have a savegame for that location? I could have a look into it.
Btw, is the border color not working at all when it's not working or it just has component order problems that you mentioned?