Rendering issue in Castlevania: Dawn of Sorrow

[windwakr]

This boss in Catlevania Dawn of Sorrow(game code NTR-ACVE-USA) has an issue where the overlap of the arm segments near his elbow will flash black.

Affects both the software renderer and OpenGL renderer. I've verified that it does not happen on real hardware.

Here is a save file right before him. He's to the left of the save room.
Castlevania.-.Dawn.of.Sorrow.zip

[zeromus]

Can you find a capture from hardware of this game at this point? This seems like a strange thing for us to be getting wrong. It's a complex game. I'd say there's a chance it's bugged in the original game. Not a big chance, but.. a chance.

[windwakr]

Here's a vid I took. Ignore the tiny blinking red spot near the center, it's a reflection from my phone.
vid.webm

I've also found that old versions of DeSmuME don't have this issue.

EDIT: Here's a direct capture video I found on YouTube:
https://youtu.be/qnVqKDXlZeI?si=yHjOEA4t0-ofyZkF&t=1029

[zeromus]

ok, well done. thanks.

[rogerman]

@windwakr: Can you confirm which version of DeSmuME didn't have this issue? I tried all the way back to v0.9.8 and I still saw the graphical issue. Also, for the version that did work, were you running SoftRasterizer or OpenGL?

[windwakr]

0.9.6 seems to be the most recent release that doesn't have the flickering. Renderer doesn't matter.

[zeromus]

there is a pitch black piece intentionally placed behind the normal visible piece, in order to create the effect of a dark part of the body perpendicular to the screen. note the visible piece kind of "fades out" near its joint further up the arm, where it "blends" into the black piece.

I dont think it has to do with the sorting. It must be that the depth values are getting disordered. But you would expect that system to be really resilient in this game. If you look at it really closely it seems to glitch on certain Y-positions but I just wasn't able to get the sorting to affect it. Actually the game should be z-ordering everything properly.

One theory is that the designers goofed up and picked the same Z value for both those pieces (a flaw in their otherwise resilient system) and so it depends on very fine details of our geometry pipeline. I think my next step would be to print all Z values rendered and look for a tie.

I tried to get a renderdoc capture going but it was really hard. There's so many contexts in flight here (and I have to switch them all to core profile) that renderdoc has a hard time capturing it. I could see part of the level rendering sometimes, but it would stop like 4/5 through rendering the backdrop tiles and then go into another scene. I tried to enable single-threaded mode (otherwise, are we presenting the screen in another thread while rendering the opengl in yet another thread?) and ran into lots of agg crashes (bitrotted code in single thread mode) and after bashing through those, I got nonsense captures with lots of errors that looked like major opengl programming errors.

I really like debugging stuff with renderdoc nowadays.. I need to put some work into rehabilitating things here so that it works.

[rofl0r]

in case the git history goes back to 0.9.6, git bisect is probably a good option to pinpoint the exact change breaking this.