Tomb Raider Anniversary jump to horizontal bar issue
roylaza opened this issue ยท 56 comments
What happens?
In Tomb Raider Anniversary - Egypt - Temple of Khamoon (level 9 I believe) there is a section where a jump backwards to a horizontal bar is required, however Lara doesn't extend her hand to the bar and so falls to her death.
I have uploaded a video I've shot of this in action:
https://www.youtube.com/watch?v=CMLKkRU74qM&feature=youtu.be
What should happen?
Lara should extend her hand after the jump and cling to the horizontal bar, as seen in the below gameplay footage:
https://youtu.be/_BSzFKm3RtU?t=19m5s
What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.
I am using PPSSPP Gold v1.6.3 (Android) on a Sony Xperia XZ2 with Snapdragon 845 and Adreno 630
Attached are my saved game and save state
Thank you
It would be super helpful if you could try a range of older versions from https://buildbot.orphis.net/ppsspp/ and try to narrow down when this broke. Also, you're not using the option to change the CPU clock, I assume? That can throw things like this off, we've seen that before...
Hi Henrik
Yes I will try out some older versions, I've just tested the latest version on both PC and Android and the PC version does not have the issue while the Android version does, so atleast we know this is android-specific.
I'm not changing the CPU speed
@hrydgard I've tested a few versions but the lowest I can go is v1.3-740-g5ba53addb and this version has the issue, is there a place where I can download even earlier versions?
If you go into developer tools, and switch to "IR Interpreter" instead of "Jit" (it will be slower), does this still happen? You can use a save state to avoid most of the slowness.
It might be that it never worked on Android. But it also might still be related to a setting. Make sure you're not using cheats and don't have any hacks enabled.
-[Unknown]
@unknownbrackets Amazing! you are absolutely right, switched to this option and suddenly Lara lets go of her suicidal tendencies :)
And as you've said, this slows the game down to a crawl but at least it allows to pass this part and then switch the setting back
Thank you very much!
Great, another ARM64 JIT bug then :)
Thanks guys, I'm kind of honored that my finding will help make this amazing emulator a tiny bit better :)
Here's another interesting finding:
20180614_194746.mp4.zip
(video file)
She just keeps slipping on the gate! So jit makes games smoother by making them greasy, right?! LoL
As noted, it doesn't happen on IR interpreter.
@Leopard20 That's pretty funny :) is that using my saved state? haven't notice this behavior myself.
No, I used your in-game save to progress to that point. I just figured it might've been triggered by something else. So I didn't use the savestate.
You don't notice it even when you unthrottle the game?
@Leopard20 You are right! she does slide, I guess I haven't stayed in one place long enough to see it
Another interesting finding:
JIT still works, but you have to be quick (otherwise she'll slip!) and also jump from near the left-side edge:
20180614_200343.mp4.zip
I think this slipping phenomenon is the cause of the problem, possibly at this specific area the game checks Lara's y position against a specific value and because she slips the value is wrong, which would explain why doing it quickly as you suggested bypasses the problem as the value doesn't have enough time to change
Just a guess though :)
I think this is exactly the cause!
For example, another issue with the game Tekken 6 (leg shaking) also alters the characters' hitboxes. So it's not strange that when Lara slips in this game, she can't grab the ledge or bar anymore!
Just finished the game with no other issues
@roylaza any chance you could pick this up again with a recent build, and try this? https://github.com/hrydgard/ppsspp/wiki/How-to-find-JIT-bugs,-the-easy-way
@hrydgard One thing you failed to mention in the above tutorial which I have to ask: can you simply use save states after a restart or is it still necessary to progress all over to the buggy point?
Savestates are fine.
Really? But it works with the IR jit?
It looks like it. I kept the game unthrottled for like 1 whole minute but she didn't move.
Hm. Maybe it's somehow related to vertexjit or something else that gets turned off when you use IR then?
-[Unknown]
Other things affected by jit vs ir:
- Does it work with
VertexDecJit = False
in the ini? - Jit bootstrap
- Jit branching
Everything else ought to be the same.
For branching - I had created JitBranchLog
in x86jit, which basically filled intBranchExit
and compared it on exit to make sure the interp and jit calculated the same branch. We could introduce a flag to enable this at runtime in arm64jit.
For bootstrap - we could add a flag to suppress any changes to rounding mode, but outside that it'd seem like we'd have to be overwriting something important.
Actually, rounding mode is probably the most likely difference at this point?
-[Unknown]
I didn't find this variable in the ini so I added that manually but it didn't make any difference. (added it to the game ini, not PPSSPP's)
One other thing I noticed is that IR interpreter works but Interpreter does not.
Unfortunately, VertexDecJit is not per game, it's global only. But sounds like that's not related if interpreter doesn't work.
Interesting that interpreter also does not work. I think IR Interpreter might be doing the least to respect rounding mode currently, so it makes me think there's something involving the rounding mode.
-[Unknown]
If the issue is in the interpreter, specifically on an instruction where the JIT currently falls back to the interpreter, then that would explain why turning off parts of the JIT makes no difference. IR's main weakness is rounding modes indeed, but in this case it might be that two wrongs make a right there.
Oh, that's a good point. There are some vfpu instructions we implement only in IR, I think.
-[Unknown]
If one of those fixes it, then the technique of turning off parts of the JIT could be used with the IR Jit as well...
Right. @Leopard20 to confirm, does it work in IR interpreter even with all the features disabled? Even though it isn't truly a jit, it still operates the same way - those same flags control it too.
-[Unknown]
No. Disabling all Jit features breaks things again. Let me narrow it down...
Done. VFPU_MTX is the one that breaks it.
I only checked the first 10 features.
vmmov -> IR only does the zero overlap case, seems unlikely to differ.
vmscl -> IR only does zero overlap (vt/vd) and 4x4. Not seeing a difference.
vmmul -> IR only does zero overlap (all three). The fallback algo is pretty similar. Involves a multiply so rounding could matter (but I think jit calling interp uses jit rounding)?
vtfm -> IR handles overlap. These are a bit more different but do seem to operate the same... also involves multiply.
Hm.
-[Unknown]
There's a chance #11926 might affect how this runs in IR Interpreter.
If it breaks it the same way as interpreter and arm64jit, maybe it means we're not transposing something elsewhere correctly...
-[Unknown]
That pull request seems to have fixed the Interpreter issue (which is weird because that was a fix to IR, right? Or maybe some other commit is responsible?). JIT is still broken.
Hmm, that specific pull request only changes code that runs for the "IR Interpreter", so it really shouldn't be able to change the behavior of the regular Interpreter. Maybe another commit (like the vsocp commit) fixed something in Interpreter?
So to confirm, the current state is:
- Interpreter - works
- IR Interpreter - works, jit disable flags set or not
- Jit (arm64) - works with VFPU_MTX disabled (checked), broken otherwise
Is that right? Or is it now a different flag for jit?
-[Unknown]
@unknownbrackets Correct.
However I just noticed another issue. When I move sideways, it's like the ledge is not horizontal but rather is slanted. This is a new issue, possibly caused by the same commit.
Can you test in the latest git build? It now has disable settings for multiple mtx ops, so we can narrow it down further.
-[Unknown]
Disabling VFPU_MTX_VMMUL fixes the issue.
@unknownbrackets Another interesting finding: Disabling this very feature actually helps the Tekken 6 trembling legs issue #5399 (doesn't fix it completely, but the legs tremble very, very little in comparison and not as noticeable)
@Leopard20 You're sure about the Tekken 6 leg trembling, and it's not just that the leg trembling varies a lot between levels? If this helped it would be surprising since the leg trembling has been observed on x86 as well, which does not have the other issues that seem to be caused by this instruction on ARM64.
From what I recall from looking at it - leg trembling in tekken is affected by:
- distance to the center of the arena, doesn't exist at exact (0, 0) coordinates, get's more broken the further from the center it goes and the coordinates in that game get's really high values really quickly when moving out of the center - the starting position is already around 20000.0,
- by character pose - the further from the character center the legs get, the more they tremble, so standing on one leg in the center will not have noticeable trembling.
It's not affected by map itself, but ofc bigger/infinite arena will allow going further from the center, same as different characters will have different pose also affecting the visibility of the problem.
Well, the 0,0 coordinates of each arena is not necessarily where the players are? Or is it?
It was in the center, between starting position, but I probably didn't saw all of the maps.
I can confirm the leg trembling in Tekken6 was minimize by disabling VFPU_MTX_VMMUL but my phone is arm32 ๐
Huh, that's really interesting...
@hrydgard See for yourself:
VFPU_MTX_VMMUL enabled
Screenrecorder-2019-06-04-20-54-53-158.zip
VFPU_MTX_VMMUL disabled (checked)
Screenrecorder-2019-06-04-20-54-09-146.zip
So "improved" basically ends up looking as it always was on x86-64.
I'm not sure "improved" is the right word, but at least it should do the same computation this way.
Also, the fact that this seems connected to Tekken 6 trembling makes me think that we really should try to figure out how the PSP's dots and matrix mults really work and get as close as possible.
@hrydgard Your commit fixed the issue.
@Emulatorer Does it look the same on your phone (I mean Tekken 6)?
Does the ledge thing still happen?
-[Unknown]
If you mean the "slanted ledge" issue, yes. But this also needs testing on the real hardware.
Slanted edge looks pretty weird. Do any of the JIT disable settings affect it?
No. Neither does switching to (IR) Interpreter
OK, then I agree it needs hardware testing as it might be a game bug.
The really bad part of this is almost certainly fixed now, so bumping to 1.10.