[Recluse]

Bump mapping and self-shadowing were disabled on macOS. Enabling the existing shaders produced invalid Metal shaders through DXVK/MoltenVK.

The macOS renderer now uses the R32F shadow-map path with a DXVK sampler patch. The path is enabled with OPTION_MACOS_D3D9_SHADERS=ON.

Bump-map conversion also cast negative normal components directly to unsigned bytes, causing black speckling on models. Converting through a signed integer preserves the normal components and removes the artifact.

[IonAgorria]

Hello, the provided pictures don't seem to be rendered correctly with blackened areas in the objects ...

[Recluse]

Thanks for pointing this out. I'll compare it with the rendering in the original game on Windows today and try to fix the differences.

[Recluse]

The black speckling came from bump-map conversion in the local D3DX implementation. Negative normal components were cast directly from float to uint8_t, which is undefined for values outside that type’s range. Converting through a signed integer first fixes the corrupted normals.

UBSan reproduced the invalid conversion; the corrected conversion passes all 256 input channel values. I also checked the macOS build with bump mapping enabled: the speckling is gone from both the menu frame and the buildings.

For comparison, I tested a Windows build containing these PRs with native D3D9. The menu frame rendered without this artifact with bump mapping and self-shadowing enabled.

[IonAgorria]

Interesting, I wonder why happens on MacOS and not on Linux where we use the same D9DX impl and DXVK 🤔 do you have Linux? also a good way to see bump mapping in action is Cluster's frame with sun reflecting on the panels

[Recluse]

I'll try to install Linux on my PC this weekend so I can compare the rendering on real hardware, including Cluster's frame with sunlight on the panels. Thanks for the suggestion.

The macOS build uses DXVK through MoltenVK to Metal, but this particular fix is in the CPU-side normal conversion. The old code casts negative floating-point values directly to uint8_t, which is undefined for the values involved; the change converts through int8_t first. UBSan flagged the original conversion, and the change removed the visible artifacts on my Mac.

That could explain why the same code behaves differently on ARM64/macOS and x86/Linux, but I haven't verified the Linux side yet.