Metal Arms: Glitch in the System Shadow Transparency/Fade Issue

[zstorm4]

Title

https://xemu.app/titles/5655000a/

NTSC

Bug Description

On hardware, player shadows have transparency and fade at a distance.
When emulated in xemu, shadows are fully opaque and do not fade correctly.

In render doc, stage 3 of the pixel shader causes the opaqueness. If you comment/remove stage 3 of this shader, the shadow renders more accurately. This is probably not the appropriate solution, but for documentation's sake has been included below. In addition, I am making this issue on behalf of the user who discovered it.

Xemu Example 1:

Hardware Comparison 1:

Xemu "Modified" 1:

Xemu Example 2:

Hardware Comparison 2:

Xemu "Modified" 2:

Shadow Fade Xemu Capture:
https://user-images.githubusercontent.com/11667457/173250324-62e94be0-5131-472e-9034-e47a783629c7.mp4

Shadow Fade Hardware Capture:
https://user-images.githubusercontent.com/11667457/173250512-55638e72-6a6c-4f7d-93cf-6eee28605de9.mp4

Expected Behavior

Shadows should be semi-transparent. In addition, shadows should fade from semi-transparent to non-existent, currently they are entirely visible until they reach the threshold they should disappear.

xemu Version

Version: 0.7.32
Branch: master
Commit: 3082949
Date: Fri Jun 10 23:30:50 UTC 2022

System Information

CPU: AMD Ryzen 7 3700X 8-Core Processor
OS Platform: Windows
OS Version: Windows
Manufacturer: NVIDIA Corporation
GPU Model: NVIDIA GeForce RTX 3070/PCIe/SSE2
Driver: 4.0.0 NVIDIA 512.95
Shader: 4.00 NVIDIA via Cg compiler

Additional Context

Levels tested are mil factory in multiplayer (to the right of the door where the black rivet grunt spawns) and Seen Better days after the scripted destruction of the gate.

[abaire]

It's much more likely that this is a vertex shader problem than a combiner issue. I'd suggest looking at texture sampler 1 to see what kind of texture is being applied, in particular its alpha value, and compare that to a hardware dump w/ nv2a trace (or use common sense). I often find that textures are created with some bug in the alpha channel many draws before they're applied and manifest in a visible issue.

[abaire]

Might also be worth quickly testing with #1045 and/or #913 as both of these lead to cases where calculations are incorrectly set to 1.0 or 0.0.

[zstorm4]

Just tested both builds, identical results to this issue, looking into setting up nv2a trace and will report back

[zstorm4]

It's much more likely that this is a vertex shader problem than a combiner issue. I'd suggest looking at texture sampler 1 to see what kind of texture is being applied, in particular its alpha value, and compare that to a hardware dump w/ nv2a trace (or use common sense). I often find that textures are created with some bug in the alpha channel many draws before they're applied and manifest in a visible issue.

I'm attaching an upload of an nv2a-trace I just ran for an hour or so, command 5960 specifically is the shadow texture used here, it does not have an alpha for texture sampler 1.

link removed lol

[abaire]

It's much more likely that this is a vertex shader problem than a combiner issue. I'd suggest looking at texture sampler 1 to see what kind of texture is being applied, in particular its alpha value, and compare that to a hardware dump w/ nv2a trace (or use common sense). I often find that textures are created with some bug in the alpha channel many draws before they're applied and manifest in a visible issue.

I'm attaching an upload of an nv2a-trace I just ran for an hour or so, command 5960 specifically is the shadow texture used here, it does not have an alpha for texture sampler 1.

Please don't post nv2a-trace dumps, they typically contain raw assets that are likely not allowed to be shared.

I'd be relatively surprised if there's really no alpha since there are easier ways to pass r0 alpha through than multiplying by a texture sample with an alpha channel that would either be set to 0 or 1 (both of which are also trivially easy to use via combiner values rather than texture sampling).
I'd suggest checking the help options for nv2a-trace as by default it discards alpha to preserve the existing behavior before I extended it
You probably also want to disable RDI dumping as it is extremely slow and generally not useful unless you're debugging vertex shader constants.