[BUG] Beyond Good and Evil demo: broken characters.

[ghost]

Describe the bug In the demo of Beyond Good and Evil (issue 85 of the eu magazine), the characters in the demo are broken no matter which settings:

MicroVU0:

Note: It's one rare case where VU0 interpreter is worse than microVU:

To Reproduce Load the game, go into the 2nd part of the demo.

Expected behavior The characters should be displayed exactly like the full game.

Emulation Settings VU0 kickstart to avoids sps.

System Info (please complete the following information): PCSX2 Revision: pcsx2-v1.7.0-dev-877-g6c81bb54f-windows-x86 OS: Windows 10 CPU: I9 9900k GPU: RTX 3070

Dumps https://drive.google.com/file/d/1MvI5OAYUgdIFbvzAvGaK_5aR68qqDe6f/view?usp=sharing

[ghost]

This is EE-VU0 timing bug. VU0 interpreter actually work fine, VU0 kickstart is what make it broken. Not sure that can be resolved with current approach for VU0 sync without breaking other games. Problem are 16 start cycles when VU0 kickstart is enabled (required for JAK).

I made some tests, and to make it work on recompiler.. Start cycles for VU0 program need to be 0 with VU0 Kickstart enabled (which is still required to fix SPS on recompiler). I even tested absolute minimum 4 required for JAK, but that also make it broken. Even then interpreter still require VU0 kickstart hack do be disabled anyway.

Maybe some MIPS/VU code rearranging will be able fix it, but imo is not worth it for 2 stage demo when you can use interpreter. Maybe if full game is also affected, then yes.

[refractionpcsx2]

Does the game not work with the kickstart hack off then?

[ghost]

Nope, on recompiler there will be still major SPS. But it fully work that way on interpreter.

[refractionpcsx2]

RIP game I guess. if it wasn't for Jak (and I think Shox), we'd be golden

[ghost]

Yeah. Just in case here is summary of tests.

Recompiler 0 startcycles, VU0 kickstart on = ok Recompiler 4 startcycles, VU0 kickstart on = broken Recompiler VU0 kickstart off = broken (SPS)

Interpreter 0 startcycles, VU0 kickstart on = broken Interpreter 4 startcycles, VU0 kickstart on = broken Interpreter VU0 kickstart off = work fine (current master)

So if someone really need to play it, currently interpreter work fine without VU0 kickstart.

[refractionpcsx2]

Interpreter makes no sense, aside from the kickstart cycles, the interpreter doesn't use the kickstart, unlike microVU

oooooh yeah, COP2 sync

[ghost]

So.. Looking at mips code i found there is QMTC2 with interlock in function responsible for light source calculation. Lack of corresponding M-bit was weird. So i went ahead, and looked what VU0 code is run by next vcallms. Added M-Bit at right place on VU0, and it worked. I think that how original code looked, then they decided that additional sync is not needed, and left unused interlock accidentally.

So with that patch and VU0 kickstart, game is playable with recompiler, and interpreter. // Add additional M-Bit sync to fix broken lights sources on characters. patch=1,EE,E001513F,extended,00491224 patch=1,EE,20491224,extended,21EA513F

Note: Rearranging code to make qmtc2 t2, vf12 before vcallms don't help, so is not that. ;)

[refractionpcsx2]

Well if there is an interlock and no M-bit, that means the function waits until VU0 has finished its program. So I dunno why the M-Bit helps.

[ghost]

Hmm, you're right, i thought that apply only to qmfc2/cfc2. But after rtfm, i see it should sync there anyway also with qmtc2/ctc2. So i have no idea why M-bit help then.. But it help.

[refractionpcsx2]

It's also possible that this is still not totally correct, as the instruction on the VU will run before the interlock (Mbit) is released, but depending on how they expect this to happen, the values the VU program uses could be different (due to them running in sync on the real console), so you have one of two scenarios happening

vf10 will have the right value and vf11 will not or vf11 will have the right value and vf10 will not.

[coornio]

The link to the dumps is fubar, someone will need to re-upload.

[Mrlinkwii]

seems a bit better on v1.7.4861

[Goatman13]

Weird colors are because qmtc2 to vf12 which is used in one of first calculations is after vcallms (on ps2 vcallms isn't triggering VU0 instantly, it takes some cycles) so with small kickstart vf12 is corrupted on VU from the start. That's first part of issue. Next is that qmfc2 series to read previous results is after vcallms too, which cause dark spots and corrupted shade. This issue affect also first part of demo (boat), but it's much less noticeable there.

0x11EE18  qmtc2        $t0, vf10, interlocked
0x11EE1C  qmtc2        $t1, vf11
0x11EE20  vcallms      2, 0x10    \__ first issue.
0x11EE24  qmtc2        $t2, vf12  /
0x11EE28  qmfc2        $t4, vf20  \
0x11EE2C  qmfc2        $t5, vf21   \__ second issue.
0x11EE30  qmfc2        $t6, vf22   /
0x11EE34  qmfc2        $t7, vf23  /

Normally running VU0 behind should be enough, but this corrupt different microprogram registers responsible for skin geometry (SPS).

Patch to fix it properly (with code check to ensure BGE demo is running).

// Rearrange code to ensure old results are read before new program starts,
// and that vf12 is updated before program starts.
patch=1,EE,e002cce0,extended,0011ee16
patch=1,EE,2011ee20,extended,482fb800
patch=1,EE,2011ee34,extended,4a0000b8

[refractionpcsx2]

The VU Sync option in the Game Fixes should run the VU ahead, does that help?

[Goatman13]

VU Sync run VU behind, doesn't it? That break different VU program (SPS).

[refractionpcsx2]

Oh goddamn, you're right, sorry, in that case the VU should immediately start then. but it will only run up until the first branch.