Pcsx2: [PAL] Final Fantasy X-2 has issues with Depth Emulation

[Hirato]

Final Fantasy X-2 crashes when you select 'Load Game' from the main menu, if both the following conditions are true:

1. The rendering resolution isn't 1x Native
2. The 'Disable Depth Emulation' user hack hasn't been enabled.

Any other combination of speedhacks, GS settings, or manual game fixes seem to have no effect.

This zip contains 2 sceenshots and a GS dump; the GS dump covers me just accessing the Load Game menu in software (at least I think it does), hopefully this is enough to find and fix the initial crash in hardware.
The second screenshot shows the corruption when you switch back to Hardware after the menu's loaded (provided it doesn't crash outright).
https://my.mixtape.moe/nqsjrd.tar.gz

There's also another issue if Depth Emulation isn't disabled. Particularly if you watch cutscenes that use the 'movie sphere' overlay, characters and scenery clip through the full screen effect and are clearly visible on screen.
This zip contains a screenshot and a gump; recorded in hardware mode at 1x Native to avoid the aforementioned crash
https://my.mixtape.moe/rzofus.tar.gz

[FlatOutPS2]

The load game crash is caused by v1.5.0-dev-615, Gsdx black fmv.

[vsub]

I can confirm...it doesn't crash if you use DX9/11 or 'Disable Depth Emulation' while using OGL

[gregory38]

Well I'm nearly sure that crash is in this function void GSTextureCache::Target::Update() It is often this one that overflow if you enable scaling.

@turtleli already reports me some bad assert. It could be linked. However I'm too busy currently. So it will wait.

[gregory38]

Hum, I changed some code around. Just to be sure, do you still have the issue?

[FlatOutPS2]

Hum, I changed some code around. Just to be sure, do you still have the issue?

Still crashed on dev-708
Fine at dev-709 !

[Hirato]

The crash is fixed.

The other issues with depth emulation still persists though.
This one has a screenshot of the main game menu and a corresponding GS dump.
https://my.mixtape.moe/dahaxd.tar.gz

[gregory38]

the depth issue exists in 1x too?

[gregory38]

and is it a new issue or an old one?

[Hirato]

The issue(s) shown in dump 2 and 3 occur at 1x Native whilst depth emulation isn't disabled.

I'm not sure how to answer the question about it being new or old;
I didn't see a ticket for it, and it wasn't introduced by any recent changes.

[gregory38]

Hum, I found an interesting bug trying replaying your gs dump. I don't think it was your issue but could you give a shot to the latest git.

Edit: I try the game and the issus is stil here, but I didn't manage to create a dump to reproduce it.

[Hirato]

Was a good find though, the background in the save game menu is no longer corrupted.

The cutscene with shuyin is still wrong and the in-game menu is still wrong.
Though very curiously, after I played the cutscene with shuyin and opened up the in-game menu, it showed up completely correctly, but when I closed and reopened it it was corrupted again.

[gregory38]

I have a gs dump that reproduce the issue in the menu. I have a glitch on the top-left corner, do you have the same.

• Issue nb1: the depth texture is partially invalidated, only the top left-corner,
• Potential issue nb2: depth texture is wrongly written in the gs memory. I suspect that it impacts the SW renderer too. You don't see it due to a previous rendering.

@gabest11 I need your confirmation on the behavior. I will post a gs dump (tonight) if you need it.
The game writes depth data from EE (GSState::Write). However the trick is that base pointer isn't aligned on page boundary. Instead the game does the following write (4 blocks by 4 blocks). Format is 24Z.

• bp 0x2100 size 16,16
• bp 0x2104 size 16,16
• bp 0x2108 size 16,16
• bp 0x210C size 16,16
  and so on...

So it will call GSLocalMemory::WriteImage24Z and set write the block with

GSBlock::UnpackAndWriteBlock24(src + (x - tx) * 3, srcpitch, BlockPtr32Z(x, y, bp, bw));

Now, let's look the block number function. (x and y will be 0,0 ; 8,0 ; 0,8 ; 8,8). I have the feeling the function only work correctly if bp is aligned on a page boundary.

    static uint32 BlockNumber32Z(int x, int y, uint32 bp, uint32 bw)
    {
        return bp + (y & ~0x1f) * bw + ((x >> 1) & ~0x1f) + blockTable32Z[(y >> 3) & 3][(x >> 3) & 7];
    }

Let's say we want to write to the block 0x2100 (aligned on a page boundary). x < 16 and y < 16
So

• bp <= 0x2100, smallest value set by the game is 0x2100.
• bp = 0x2100 => (y & ~0x1f) * bw + ((x >> 1) & ~0x1f) = 0 and blockTable32Z[(y >> 3) & 3][(x >> 3) & 7] = 0
• blockTable32Z[(y >> 3) & 3][(x >> 3) & 7] = 0
  => (y >> 3) & 3 == 2 => y == 16
  => (x >> 3) & 7 == 4 => x == 32
  It isn't valid because both x and y are strictly below 16.

So if I understand it correctly, bp must be either below 0x2100 or the function only works if bp is aligned on page boundary. Hum, hum, or maybe this macro is wrong

bool aligned = IsTopLeftAligned(TRXPOS.DSAX, tx, ty, 8, 8);

As you know, unlike color format, Z format doesn't start at the top left.

What do you think?

[Hirato]

i can't speak for the dump, but for the ingane menu there's a left column
of sorts that is shaded properly.

the rest of it is darker than it should be. I'm not sure if the shadows are
obscured, but a model of the planet is missing. and there is also a weird
banding effect across the right side that looks similar to the wavey
background most of the dialogue boxes use.

[gregory38]

Ok, I think it is related to the first issue. The depth buffer isn't cleared due to the bad invalidation.

[gregory38]

@Hirato 156f1b70c30e0720b8f37a77f71c03715e85cf96 shall improve the situation.

[Hirato]

Can confirm the menu is now rendering correctly.

[Hirato]

Since your commit also asked about SMT3 and DDS. I noticed in DDS that shadows no longer clip through people's legs, not sure if that's related to that commit or not, but otherwise I don't see anything different - at least for DDS

EDIT: mostly mentioning that because I know it is (or was) a problem for SMT3

[gregory38]

Please could you check older build to be sure it is related to this build. Thanks you.

[Hirato]

I checked SMT3 as well, it seems the shadows were fixed somewhere between 5de1600 (about 200 commits ago) and 7a5e1d4 (about 90 commits ago).

I don't have any packages built for revisions inbetween, so I haven't tested them.
In any event, the shadows in SMT3 are fixed and the commits related to this bug had nothing to do with it.

[gregory38]

It ought to work on latest release granted that you don't disable depth emulation and keep crc hack level low enough.
So there is no regression on those games and current issue can be closed.

I think the previous issue on depth transfer is likely a "game" issue that doesn't properly clear the Z buffer.

[Hirato]

Do you mean closing this issue or just this tangent about DDS/SMT3?

For this issue, the problem shown in the second dump in the opening post in which shuyin (and other model geometry) clips through the fullscreen effect is still present with depth emulation.

[gregory38]

Well I mean this one. But it seems it isn't perfect yet.

[gregory38]

Please retest latest git

[Hirato]

That cutscene is rendering correctly now.

[ssakash]

I think conditional checks like these aren't ideal ;)
else if (m_type == DepthStencil && m_renderer->m_game.title == CRC::FFX2)

It'd be better to have a more nicer check for bad invalidation.

[gregory38]

The good fix would be to handle invalidation properly but it is such a nightmare. It will likely break others games. Besides it won't solve the block/page boundary issue. So yes it is dirty but that is probably the best solution so far.