graphics issues in Ninja Gaiden black and DOA2U

[ko81e24wy]

I upload them in one post,cause they may use same engine,and have similar graphics issues title:54430006 some high-light effect(or bloom?) missing（also in Ninja Gaiden） title:5443000d and some shadow problems(sometimes missing,sometimes incorrect) fixed by #778 some steam effect broken in chapter 12,
fixed by #599 and this issue may some anti piracy thing?

[SK91no]

The last bit there isn't an anti-piracy measure, its a bug the Discord user Caroline has given a possible explanation so look it up in the Discord search bar if you can with the keyword "Ryu"

[ko81e24wy]

The last bit there isn't an anti-piracy measure, its a bug the Discord user Caroline has given a possible explanation so look it up in the Discord search bar if you can with the keyword "Ryu"

yes,I had try that way,its a good solution,but not perfect.if you set the texture transparent,the evil RYU costume in chapter 15 will be incorrect.

[vanderleivieirainacio]

So is it possible to fix this Ryu Hayabusa bug? If possible, would it be very difficult to make this correction?

[ko81e24wy]

So is it possible to fix this Ryu Hayabusa bug? If possible, would it be very difficult to make this correction?

I think it is possible in the future,and the fix will make other games better.but now its good enough to enjoy the game .so let's be paient.

[vanderleivieirainacio]

Ok, thanks for the information and for taking time to answer my question.

[micjgam]

So... are the steam effects able to be fixed? Does this same issue exist in ch. 16?

[ko81e24wy]

test with this build(#599 ) https://github.com/mborgerson/xemu/actions/runs/1698535861 fiend texture were fixed,still has stream issues in chapter 12 mater build before this pr

599

[abaire]

pgraph dump of the issue in the Magma Cavern level

ngb_steam.txt

The heat shimmer is applied to a 512x256 capture of the backbuffer after the full scene is rendered. An alpha blended 128x128 white circle is used as the second texture input.

Shaders used in the initial pass: ngb_vs.glsl.txt ngb_fs.glsl.txt

In my particular test case, the framebuffer is 720x480. In the initial shimmer pass, I see that it appears to center the 512x256 texture with clamping happening on the left and bottom. This is extremely pronounced if I temporarily disable the alpha adjustment in the second stage combiner:

Texture border color is set to white, which probably explains why it looks like white steam. LOD_BIAS for the framebuffer texture is set to 7937, for the cloud texture it's 0. The minification filter for the framebuffer texture is set to TENT_NEAREST_LOD

Texture planes for stage 0:

c[64] 1.00, 0.00, 0.00, 0.00 float4
c[65] 0.00, 1.00, 0.00, 0.00 float4
c[66] 0.00, 0.00, 1.00, 0.00 float4
c[67] 0.00, 0.00, 0.00, 1.00 float4

There's also a texture matrix enabled for texture 0:

0.708939, 0.000000, 0.515000,  0.000000,
0.000000, 1.260336, 0.490000, 0.000000,
0.000000,  0.000000, 0.000000, 0.000000,
0.000000, 0.000000, 1.000000, 0.000000

SKIN_MODE is set to off

Alpha kill is enabled on the cloud texture. Interestingly if I set the threshold to something higher than 0.0 (e.g., 0.25), I see a shape that looks more plausibly correct (the shimmer effect is still wrong, but seems to float over lava pools).

I also see that TEXGEN S, T, and R are all set to 0x2400 = EYE_LINEAR, which seems like it may be an interesting place to start investigating.

[abaire]

The white contribution is actually not due to the border color, so somehow the second texture channel is being rendered to screen directly. This is particularly strange as the combiner does not use the t1 color channel at all; all color comes from t0 (the downscaled backbuffer content).

Edit: On closer inspection, the captured framebuffer has 1 pixel white lines along the top and right, so this is entirely explainable by the edge clamping behavior that is seen along the left and bottom edges.

[abaire]

It looks like the combination of texgen + texture matrix leads to incorrect behavior. I wrote tests for texgen and texture matrix individually and both appear to match hardware, but a test using both differs dramatically (it appears to disregard the texture matrix)

[abaire]

It looks like the issue is that the Q and R generation planes are swapped. Switching them gives reasonable output:

It's not entirely clear to me why this is the case, but the actual values do look wrong (the constant at 0x42 is [0,0,1,0] which looks like it should be R, but is assigned to Q; the constant at 0x43 is [0,0,0,1] which looks like it should be Q).

I'm not sure if this is dependent on the texgen mode or if it's actually indicative that the texture matrix needs to have rows swapped.

[ko81e24wy]

test PR #778,fix the graphical issue in CH12 https://www.youtube.com/watch?v=ahl9URuvbLw

[mborgerson]

Can you re-file any issues that persist (e.g. dim lighting) individually so we can track them independently @ko81e24wy

[ko81e24wy]

open a new issue or just edit this one?

[mborgerson]

@ko81e24wy just open a new issue for each one that persists, so we can have a clean slate

Thanks in advance!

[ko81e24wy]

@ko81e24wy just open a new issue for each one that persists, so we can have a clean slate

Thanks in advance!

will do.