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 2026-01-11, 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?

Dege wrote on 2026-01-11, 16:06:

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 wh […]
Show full quote

Cambid wrote on 2026-01-11, 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?

This is a checkpoint just before that location. It's for the retail PC version with stock maps (not custom edition). To use it put it in "\My Games\Halo\savegames\"whatever your profile name is"\checkpoints\". I'm not exactly sure what the correlation is but I can farily reliably reproduce it here if I load up the level Keyes, run around for a bit, then load up that checkpoint on my 5700XT. I have a feeling it's GPU dependent as I can't reproduce it on my ancient Intel HD 4000 laptop (barely d3d11 capable).

It seems the border color isn't working at all when it's not working. It doesn't appear to be the component order issue that DXVK has. It consistently works if I change the mip filter for that sampler to none or point instead of linear.

Thanks, I'll look into it.

Cambid wrote on 2026-01-12, 10:54:

Dege wrote on 2026-01-11, 16:06:

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 wh […]
Show full quote

Cambid wrote on 2026-01-11, 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

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?

This is a checkpoint just before that location. It's for the retail PC version with stock maps (not custom edition). To use it put it in "\My Games\Halo\savegames\"whatever your profile name is"\checkpoints\". I'm not exactly sure what the correlation is but I can farily reliably reproduce it here if I load up the level Keyes, run around for a bit, then load up that checkpoint on my 5700XT. I have a feeling it's GPU dependent as I can't reproduce it on my ancient Intel HD 4000 laptop (barely d3d11 capable).

It seems the border color isn't working at all when it's not working. It doesn't appear to be the component order issue that DXVK has. It consistently works if I change the mip filter for that sampler to none or point instead of linear.

I had a little time so I wanted to look into it. But I cannot find that place.
The checkpoint you attached gets me into this gameplay:
https://www.youtube.com/watch?v=ONw77tlKji0

A litte bit offtopic but I noticed that certain scene demos and games, like Halo itself, have rendering glitches here and there if played through D3D12 on Win11 with triangle fan support reported (modern drivers). Like this, from candytron:

If triangle fan support is present then dgVoodoo runs on the most performant, zero-copy rendering path. In fact, this seems to be the case with native modern drivers as well (because I get the same glitches) like the D3D9 native driver of the RTX 5060Ti.
Old contemporary D3D9 implementations probably created copies of data coming from certain vertex/index buffers inside the D3D9 Draw-calls so misusing the D3D9 API didn't affected the result.

I decided to bring back this "compatible behavior" through D3D12 (in the next version): if feature level 11.0 is selected then the D3D12 backend disables triangle fan support and runs on the old path. It changes nothing for old GPU's with FL11.0-only support because they did not report triangle fan support in the first place. Summarized:
- D3D12 FL11.0: compatibility mode through D3D12
- D3D12 FL12.0+: most performant zero-copy mode through D3D12

Dege wrote on 2026-02-15, 15:48:

I had a little time so I wanted to look into it. But I cannot find that place. The checkpoint you attached gets me into this gam […]
Show full quote

Cambid wrote on 2026-01-12, 10:54:

Dege wrote on 2026-01-11, 16:06:

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?

This is a checkpoint just before that location. It's for the retail PC version with stock maps (not custom edition). To use it put it in "\My Games\Halo\savegames\"whatever your profile name is"\checkpoints\". I'm not exactly sure what the correlation is but I can farily reliably reproduce it here if I load up the level Keyes, run around for a bit, then load up that checkpoint on my 5700XT. I have a feeling it's GPU dependent as I can't reproduce it on my ancient Intel HD 4000 laptop (barely d3d11 capable).

It seems the border color isn't working at all when it's not working. It doesn't appear to be the component order issue that DXVK has. It consistently works if I change the mip filter for that sampler to none or point instead of linear.

I had a little time so I wanted to look into it. But I cannot find that place.
The checkpoint you attached gets me into this gameplay:
https://www.youtube.com/watch?v=ONw77tlKji0

It would do that if the map files are different to the ones the checkpoint was made on. That checkpoint was made on the stock english maps. Different language versions have different maps so would break that checkpoint. Otherwise not sure why it wouldn't work.

Cambid wrote on 2026-02-17, 10:04:

Dege wrote on 2026-02-15, 15:48:

I had a little time so I wanted to look into it. But I cannot find that place. The checkpoint you attached gets me into this gam […]
Show full quote

Cambid wrote on 2026-01-12, 10:54:

This is a checkpoint just before that location. It's for the retail PC version with stock maps (not custom edition). To use it put it in "\My Games\Halo\savegames\"whatever your profile name is"\checkpoints\". I'm not exactly sure what the correlation is but I can farily reliably reproduce it here if I load up the level Keyes, run around for a bit, then load up that checkpoint on my 5700XT. I have a feeling it's GPU dependent as I can't reproduce it on my ancient Intel HD 4000 laptop (barely d3d11 capable).

It seems the border color isn't working at all when it's not working. It doesn't appear to be the component order issue that DXVK has. It consistently works if I change the mip filter for that sampler to none or point instead of linear.

I had a little time so I wanted to look into it. But I cannot find that place.
The checkpoint you attached gets me into this gameplay:
https://www.youtube.com/watch?v=ONw77tlKji0

It would do that if the map files are different to the ones the checkpoint was made on. That checkpoint was made on the stock english maps. Different language versions have different maps so would break that checkpoint. Otherwise not sure why it wouldn't work.

I did a clean Halo CE install and tried the savegame on that.
Do you know the name of that level? I could download a savegame somewhere with all levels completed and check it out by save name.