Super Monkey Ball Deluxe: cutscenes not rendering

[Logandros]

Title

https://xemu.app/titles/53450038

Bug Description

When starting the game on storymode the cutscenes before the levels do not render.

Steps to reproduce the issue:

1. Launch game
2. Select Main Game
3. Select Story Mode
4. Choose a save slot and a name
5. Expected cutscene is not shown (hitting start will skip to playable game)

Expected Behavior

Should show a cutscene, below is the cutscene that should be showing.

xemu Version

0.6.1-12-ga8c73197da

System Information

os_platform: Windows
os_version: Windows
cpu: Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
gl_vendor: NVIDIA Corporation
gl_renderer: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2
gl_version: 4.0.0 NVIDIA 510.10
gl_shading_language_version: 4.00 NVIDIA via Cg compiler

Additional Context

No response

[Logandros]

https://youtu.be/jgISwaWRUC8?t=82

In case this helps

[Triticum0]

Should retest @Logandros

[jyetcv]

There continues to be blackness covering the cinematic in version 0.8.34:

smbdx.mp4

[Triticum0]

Might be fixed with #1780

[Logandros]

I will check back when 1780 is implemented, issue persists.

[Triticum0]

Rested on masters still and issue here a renderdoc for debugging : https://drive.google.com/file/d/1pXYNVEjk9mFS7RG6X-UKOnVd4bz8n_4P/view?usp=sharing

[abaire]

I believe this one is not the same as #2200, oFog is set to the default value of 1.0 and, more importantly, is not used in the final combiner at all for the first draw (which is where the missing background texture is applied).

vec4 t0 = textureProj(texSamp0, norm0(pT0.xyw));
vec4 t1 = vec4(0.0, 0.0, 0.0, 1.0); /* PS_TEXTUREMODES_NONE */
vec4 t2 = vec4(0.0, 0.0, 0.0, 1.0); /* PS_TEXTUREMODES_NONE */
vec4 t3 = vec4(0.0, 0.0, 0.0, 1.0); /* PS_TEXTUREMODES_NONE */
vec4 r0 = vec4(0);
r0.a = t0.a;
// Stage 0
mux_sum.rgb = clamp(vec3(((t0.rgb * c0_0.rgb) + ((1.0 - clamp(vec4(0.0).rgb, 0.0, 1.0)) * c1_0.rgb))), -1.0, 1.0);
mux_sum.a = clamp((((t0.a * c0_0.a) + ((1.0 - clamp(vec4(0.0).a, 0.0, 1.0)) * c1_0.a))), -1.0, 1.0);
r0.rgb = mux_sum.rgb;
r0.a = mux_sum.a;
// Final Combiner
fragColor.rgb = max(r0.rgb, 0.0) + mix(vec3(max(vec4(0.0).rgb, 0.0)), vec3(max(vec4(0.0).rgb, 0.0)), vec3(max(vec4(0.0).rgb, 0.0)));
fragColor.a = max(r0.a, 0.0);
int fragAlpha = int(round(fragColor.a * 255.0));
if (!(fragAlpha > alphaRef)) discard;

Modifying the fragColor in the fragment shader has no effect, so I'm guessing the geometry is being projected incorrectly. If I hardcode the vertex shader's Z coordinate to be 0.0 the background image appears.

I think we need a pgraph trace for this one. You can hopefully use my work branch and the instructions here to get a trace for the same frame as a renderdoc cap so they can be compared directly.

[Triticum0]

OK will do

[Triticum0]

@abaire Here the new renderdoc + Pgraph trace.
https://drive.google.com/file/d/1CyVuc63tMFG5Xug3-VgwX8U2zvhvD1Xk/view?usp=sharing

xemu.log

[abaire]

Thanks for the capture, here's the vertex shader for context:

void main() {
  /* Slot 0: 0x00000000 0x00CC001B 0x08361800 0x20B08800 */
  DPH(oPos,x, v0, c[96]);

  /* Slot 1: 0x00000000 0x00CC201B 0x08363800 0x20B04800 */
  DPH(oPos,y, v0, c[97]);

  /* Slot 2: 0x00000000 0x00CC401B 0x08365800 0x20B02800 */
  DPH(oPos,z, v0, c[98]);

  /* Slot 3: 0x00000000 0x00CC601B 0x08367800 0x20B01800 */
  DPH(oPos,w, v0, c[99]);

  /* Slot 4: 0x00000000 0x0047401A 0xC4355800 0x20B0E800 */
  MUL(oPos,xyz, R12.xyz, c[58].xyz);

  /* Slot 5: 0x00000000 0x06CFE21B 0x1837FBFF 0x10B88848 */
  DPH(oT0,x, v1, c[127]);
  RCC(R1,x, R12.w);

  /* Slot 6: 0x00000000 0x0217E000 0x0800106F 0xF0A0F81C */
  MOV(oD0,xyzw, c[191]);

  /* Slot 7: 0x00000000 0x00D0021B 0x18361800 0x20A04848 */
  DPH(oT0,y, v1, c[128]);

  /* Slot 8: 0x00000000 0x0087601A 0xC400286A 0xF0B0E801 */
  MAD(oPos,xyz, R12.xyz, R1.x, c[59].xyz);

  oPos.x = 2.0 * (oPos.x - surfaceSize.x * 0.5) / surfaceSize.x;
  oPos.y = -2.0 * (oPos.y - surfaceSize.y * 0.5) / surfaceSize.y;
  oPos.z = oPos.z / clipRange.y;
  oPos.w = clampAwayZeroInf(oPos.w);
  oPos.xyz *= oPos.w;
  oFog = vec4(1.0);

  vtxD0 = clamp(NaNToOne(oD0), 0.0, 1.0);
  vtxB0 = clamp(NaNToOne(oB0), 0.0, 1.0);
  vtxFog = oFog.x;
  vtxT0 = oT0;
  vtxT1 = oT1;
  vtxT2 = oT2;
  vtxT3 = oT3;
  gl_PointSize = oPts.x;
  vtxD1 = vec4(0.0, 0.0, 0.0, 1.0);
  vtxB1 = vec4(0.0, 0.0, 0.0, 1.0);
  gl_Position = vec4(oPos.x, oPos.y, 2.0*oPos.z - oPos.w, oPos.w);
}

The nv2a vertex shader is generating Z values of 16777214, very close to the configured clip max (which is the typical 16777215). The projection done within the GLSL shader turns these into z=1, causing them all to get clipped.

Slightly perturbing the W coordinate used when offsetting Z in the gl_Position assignment in the vertex shader resolves the problem on OpenGL and generates a correct looking image:

It is also possible that the GLSL shaders are generating values that end up being 16777215 when run on HW, I tested with nv2a_vsh_debug which runs on the CPU.

---

@Triticum0 can you check to see if this problem happens on Vulkan (just a yes/no is enough, I don't need a capture). Vulkan doesn't perform the clip range fixup that GL does and I'm curious if that changes anything.

[Triticum0]

yes it happens on vulkan