Midnight Club 3: DUB Edition Remix - Full bright white headlights

[7HEPOW]

Title

https://xemu.app/titles/54540079/
(Seemingly the Remix version is not listed, but the regular has the same issue as of this time of writing)

Bug Description

Headlight cones turn everything they touch full white whenever using a 3rd person view.

Expected Behavior

Have the headlights brighten up things normally

xemu Version

0.7.21

System Information

CPU: 12th Gen Intel(R) Core(TM) i9-12900F
OS Platform: Linux
OS Version: Manjaro Linux
Manufacturer: NVIDIA Corporation
GPU Model: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2
Driver: 4.0.0 NVIDIA 510.73.05
Shader: 4.00 NVIDIA via Cg compiler

Additional Context

Sample image:

[abaire]

Can you attach a screenshot from an xbox showing what it should look like? It's clearly too opaque but I'm not familiar with the game and am unsure exactly what it should look like (it seems that having nothing changed directly in front of the car's lights is probably wrong as well)

[abaire]

Glancing through a renderdoc capture I see a suspiciously opaque rendering coming out of a triangle strip that includes NaN values in the diffuse components. The NaNs are not NaNs, they're type UB D3D (unsigned int) values close to pure white for the diffuse and specular components.

Looking back a few draws I see where it builds up the headlight overlay, it looks like it uses the fixed function shader w/ texgen enabled and just passes through 1.0,1.0,1.0,1.0 as the diffuse color. It does this for a number of draws, always writing to the same surface. Oddly, I see draws that appear to remove alpha from the surface, but the diffuse values in the mesh are always all 1.0. This makes me suspect a stale surface, but will need to be investigated. The draws all have colors other than alpha masked off and are using different blending operations to add/subtract from the surface.

Of potential interest: in the draws that apply the overlay, I see the vertex shader being given explicit oPts (point size) values through the weight (v1) input register, though as far as I can see point params are disabled and the INLINE_ARRAY used to pass things in does not include them (meaning they're carried over from the last explicit set).

[abaire]

I did a hardware trace and the headlight overlay texture is dramatically different from what I see in xemu+renderdoc, so things likely start going wrong there. The construction of the texture doesn't involve any other textures so this is probably fairly localized.

WRT the shape of the headlight, it's using depth comparison so #843 might be a contributing factor to things looking off. Still not sure why the blending ends up being so wrong, the depth approximation issue would not explain that.

[7HEPOW]

I roamed the internet for an XBOX screenshot, but the closest I could find was this one on a PS2 on GameFAQs:
https://gamefaqs.gamespot.com/ps2/931972-midnight-club-3-dub-edition-remix/images/24

From what it loks like, they seem to have a mesh that simply brightens up what it touches. Here's a shot from the bumper cam with regular lights and high beams, Notice how it affects the palm tree in the second shot:

High beams:

Here's also another 3rd person shot affecting a lamp post, ped and tree:

Too bad it's no compatible with the 360, as I could get a capture there.

I hope it helps in any way :)

[abaire]

Thanks, I ended up dumping my copy of the game to do a hardware trace so I've now got a good idea of what it should look like.

I strongly suspect that the opaqueness has to do with the use of signed blending. xemu maps signed blend operations to the default add/subtract glBlendOperation. I have a WIP test that uses the same mesh & pgraph settings as the relevant draws in the game and it produces dramatically different results on xemu as compared to HW. I'll strip it down to a minimal test case and then start thinking about whether we can do some trivial biasing to approximate the correct behavior or if it's going to fall into the same category as general signed textures and need more substantial work.

[abaire]

Confirmed that this is a difference in behavior related to signed blend modes.
Test
HW results

It looks like in signed mode, the source value should be interpreted as a 2s complement number, so 0xFF should be the smallest negative number rather than the largest positive. The colors are clamped to (0,1) after the operation.

This is related to #587 and will need special handling to do the blend.

[xXRaptorSc0pezXx]

I'm having this same issue. Any idea when it will get fixed?

[rvkasper]

I'm having this same issue. Any idea when it will get fixed?

seconded

[Santsku]

I'm having this same issue. Any idea when it will get fixed?

seconded

Thirded

[abaire]

I believe the underlying problem is understood and explained by my comments and the test I wrote above, now it needs somebody to do the actual work of fixing it; additional screenshots don't add any new information and just bloat this thread making it harder for somebody to follow and attempt a fix.

The nv2a supports some non-standard behavior when it comes to per-component signed blending, making it non-trivial to emulate on typical consumer GPUs, which is why it wasn't fixed when I traced it down originally.