ULJS00218 - Hitman Reborn Battle Arena 2 - Player 2 side broken/reversed/broken kick animation

[somepunkid]

What happens?

In-Game/Fights, particle effects and physics only applying correctly on Player 1 side during fights. On Player 2 side, properties operate as if they are being performed from P1 side. This leads to reversed effects and physics being applied to everything from P2 side. This effectively makes the game unstable/unplayable, since only one player side functions correctly.

What should happen?

Here is the direct comparison with the same variables on both hardware and emulation.
https://youtu.be/q1YjrLXTq7c

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues:

This was most recently tested with the UMD directly, to ensure there wasn't an issue with the source file being tested.

Win10 / Android (unknown config for android, was tested on two devices in the past and not working)
PPSSPP v1.9.3
Direct3D11/9, OpenGL, Vulkan
Nvidia 2080 Max-Q and Nvidia 970m tested with current build. Many other configs have been tested with previous builds over multiple years.

[hrydgard]

Very very odd! That has to be a CPU emulation bug... and likely not just a JIT bug. If you switch CPU core to the interpreter in developer settings, it's still the same, right?

[somepunkid]

Very very odd! That has to be a CPU emulation bug... and likely not just a JIT bug. If you switch CPU core to the interpreter in developer settings, it's still the same, right?

This is odd, and kind of hilarious! I have now tested the Interpreter/IR Interpreter settings with the same result. PPSSPP v1.9.3
Direct3D11 / Nvidia 2080 Max-Q / i7-8750H

[hrydgard]

Thanks for testing that!

[somepunkid]

Thanks for testing that!

Of course! Let me know if there's any other variables I should test using the emulator. Would be a dream to get it running 100%, big enthusiast for this specific title.

I was going through the other logs in here and it seems like these CPU emulation bugs are not super common now? Saw some older ones for Warriors Orochi/Metal Gear Acid etc I believe...

[hrydgard]

No, they are rare indeed, we've got pretty good hardware tests for most of the CPU's functionality. So something like this that looks like a really bad sign error is kind of surprising indeed...

[somepunkid]

No, they are rare indeed, we've got pretty good hardware tests for most of the CPU's functionality. So something like this that looks like a really bad sign error is kind of surprising indeed...

Is this something that is even fixable? I actually just tested it's prequel game (Reborn Battle Arena) and it is impacted with the same issue, which isn't surprising given that they share assets.

Other than that, I have not seen this in another game.

[unknownbrackets]

I definitely see the reversed thing where one character grabs another character and throws them on the ground, but I'm not sure which particle effects are wrong.

Just to be sure, could you try exporting a GE frame dump? It should be taken right when the character is being thrown wrong. I don't think it's a graphics issue, but this'll allow me to check on a PSP to make sure the wrong data is being sent to render.

The reason I say this is just because - unless I'm mistaken - it looked like the results of all the actions are "correct." So it could be possible that it's drawing it wrong, although pretty unlikely.

See here for instructions - it's not hard and works on Android too:
https://github.com/hrydgard/ppsspp/wiki/How-to-create-a-frame-dump

You can zip that and then drag and drop it into a reply here.

And wanted to note here that this was noted to happen on both Windows and Android, so it's not likely specific to any jit. That it even happens in interpreter and IR means it must either be a CPU bug that's everywhere (definitely possible) or else actually an HLE or GPU bug.

-[Unknown]

[somepunkid]

I've created a new video clip demonstrating the issue, with effects and properties being demonstrated from both sides. Directional Inputs (left right only) also reverse on the player 2 side.
https://youtu.be/TEIJRklmKTw

This causes the AI to walk the wrong way, and the properties of the moves being used to only have hit effects as if they were on the Player 1 side (see 0:19)

I took a frame dump during a different instance of the effects performing incorrectly (the shot at 0:45 posted in the above video) along with a couple other instances of reversed (Player 2 side) effects. The first file in the zip should mirror the moment at 0:45. I can create more.

Frame dump.zip

I would correct this by saying that the effects themselves are not necessarily wrong, but the impact they are having and their positioning is wrong. The correct effect is displayed, just always facing to the right.

[somepunkid]

This was done on the machine with the specs listed above, using the Direct3D 11 backend / Dynarec (JIT) CPU core option. The result of all actions play out in game as if they are only being performed from the player 1 side, except the invisible hitboxes. What is bizarre is that the hitboxes for the projectiles still appear to be impacting, but the hit effect performs as if the player is on P1, and sucks the opposing model forward rather than pushing it, and also appears on screen as if it was initiated from the player 1 side. This applies to all characters when used on the P2 side in both games.

[somepunkid]

Ah, just realized you specifically requested a dump from the throw scene. Hopefully that dump works, given that it was during one of the issues. If not, I will recreate this.

I'm thinking this might be a CPU bug/everywhere as first noted, given the game properties/issues.

[unknownbrackets]

Oh, okay, the new video makes it very obvious - sorry for not getting it before. So it does indeed affect the result.

For posterity in case it's helpful: characters are drawn using weights, and effects are not.

As a quick confirmation, this video seems to show PSP gameplay without any reversing happening (just wanted to confirm this wasn't actually just a game bug, although that seems unlikely):
https://www.youtube.com/watch?v=T3Q4v7vKTlA

-[Unknown]

[somepunkid]

All other clips can be ignored. I created this to eliminate any confusion and log this bizarre issue. This is a comparison of the game running on Hardware and immediately after in emulation, same characters and moves on the same stage.

Hardware test starts at 1:00
Emulation test starts at 3:35

https://youtu.be/q1YjrLXTq7c

[hrydgard]

That's a really, really good report video! Thanks!

No idea where to even start looking on this one though :) No clues from your interpreter, and it's clearly not just rendering...

[somepunkid]

That's a really, really good report video! Thanks!

No idea where to even start looking on this one though :) No clues from your interpreter, and it's clearly not just rendering...

Yeah, just making sure it's recorded correctly somewhere. Easier than looking through old videos. I actually tested another emulator with the exact same result.

[hrydgard]

Almost smells like we're triggering some kind of bizarre anti-piracy/anti-emulator trap...

[somepunkid]

Almost smells like we're triggering some kind of bizarre anti-piracy/anti-emulator trap...

Interesting that you'd mention this, I just started looking into that possibility. Just now. For that to be included with the first game as well, however, would be rather interesting.

[unknownbrackets]

Okay, crazy idea here, but can you also just try the software renderer? I still don't think this is graphics related, but there's an off possibility this is some crazy readback or depth thing, like Danganronpa.

Trying to think of things we do wrong even in interpreter. Some others:

• Minor rounding issues namely in VFPU (seems unlikely, but what else?)
• Short-term data and instruction caches.
• Instruction / IO timing (seems very unlikely.)
• Overlapping DMA transfer timing (seems unlikely.)
• Some HLE func impacts to stack values (uninitialized variables.)

Not sure what else...

-[Unknown]

[somepunkid]

Issue is the same with Software Rendering.

After more testing, I'm wondering if this would be the case (DRM) or if there would be a way to confirm this. The prequel with the same issue released in 2008 and I haven't known any other game to have this...this is the second release, which was pushed out in 2009.

I tried running the UMD in a PSP over USB through PPSSPP, which is where I sourced the file from. Tested multiple file/patch ideas in addition, still ran into the same thing. Tried the java-based emu as well, just for more variable tests, but no. Same deal.

I've heard of bizarre, one-off cases of games implementing obscure methods before, and I remember a number of titles around 09 had interesting attempts at destroying gameplay if it was a copy (DJMAX Portable 3 comes to mind) but I can't seem to replicate the behavior on the PSP/PSTV as well. The only thing I could think of is if it's possibly looking for specific root/directory files to be present...but I suppose it could really be anything if that can of worms gets opened.

What's the likelihood of this being something like that versus a bug I wonder?

[hrydgard]

We have seen piracy detection on the PSP, most prominently DJ MAX games that scan your memory stick and error out if they see an ISO file. So it wouldn't be the first one... That detection method was visible in our logs (once we realized what it was doing...).

[somepunkid]

We have seen piracy detection on the PSP, most prominently DJ MAX games that scan your memory stick and error out if they see an ISO file. So it wouldn't be the first one... That detection method was visible in our logs (once we realized what it was doing...).

Yes, I was aware of these methods with DJMAX. The only instance I've seen with this game running incorrectly is via emulation, however. Never on say, a PSP that has been altered. The earlier footage was from a PSTV as well. I attempted the Memory Stick Inserted unchecked option as well with this possibility in mind...

[hrydgard]

Right, okay. Really running out of ideas here...

[somepunkid]

All good! Well, if it is similar to DJMAX somehow, that's pretty funny. Some of the game protection methods can get really creative.

If it's possibly one of [Unknown]s listed ideas, well, wouldn't that be something. Some sound like a possibility!

Thanks for taking the time, to you both. It's my favorite game on the system, and I've been on a fun chase the last couple days testing the emulators and looking into older patching methods/reading old articles to see if this one had these issues on hardware.

[somepunkid]

Hey all, I did find something interesting.

https://www.youtube.com/watch?v=AqL0PlBsI5k

This is a video of someone running it on PPSSPP v.0.9.8, and it is running correctly. Supposedly on Windows. This would be the only emulated footage I've found of it running right. Is there anywhere I can test these older revisions?

[hrydgard]

Did you post the wrong link? That's just somebody scrolling in the menus.

But if it did work correctly in 0.9.8, then you know what to do - start downloading builds and find where it broke :)

[somepunkid]

Heh. It was the wrong link, corrected it. Found the build here, just had an issue with my browser. Disregard that.

[unknownbrackets]

You can download v0.9.8 here:
https://github.com/hrydgard/ppsspp/releases/tag/v0.9.8

At least the stable releases from back then are available there:
https://github.com/hrydgard/ppsspp/releases

Even knowing it broke between say v0.9.9.1 and v1.0.0 would help. The build bot doesn't keep builds that old, but we can build some as needed.

-[Unknown]

[somepunkid]

I've confirmed v0.9.8 works with default settings. I will continue testing revisions.

[hrydgard]

Cool! Seems we got lucky here that it worked back then - can't wait to see what caused this...

[somepunkid]

I did not mean to close this. Damn mobile buttons

[somepunkid]

Been getting a lot of crashes in game on Android, seemingly random during matches. Not sure if this would be related to this same issue. Crashes the whole emulator. Don't remember it doing so before...but it also had the messed up physics before so this is much more playable lol.

Haven't had this happen on Windows yet.

[hrydgard]

Huh, okay, thanks for reporting, weird that it only happens on Android. If you figure out a way to get it to crash on Windows, you could run it from within Visual Studios debugger (F5) and we could get a hint of the cause, but it's harder on Android (though ADB logs would be interesting).

[somepunkid]

Huh, okay, thanks for reporting, weird that it only happens on Android. If you figure out a way to get it to crash on Windows, you could run it from within Visual Studios debugger (F5) and we could get a hint of the cause, but it's harder on Android (though ADB logs would be interesting).

Is the process for generating these ADB logs documented anywhere? I'd be curious as to why. I've seen crashes commonly enough now to wonder :>

[hrydgard]

If you install the Android SDK, you get a command line tool called adb.exe in sdk\platform-tools under the installation directory. Run it like this from a cmd prompt to see the log output (with your Android device connected, and adb debugging in enabled in developer settings)

adb logcat -s DEBUG PPSSPPNativeActivity PPSSPP NativeGLView NativeRenderer NativeSurfaceView PowerSaveModeReceiver InputDeviceState PpssppActivity

(The long parameter list is to filter only PPSSPP-related stuff).

[somepunkid]

Done: Log

--------- beginning of crash
--------- beginning of system
--------- beginning of main
10-12 01:34:27.720 20734 20734 E PpssppActivity: Got ACTION_VIEW without a valid uri, trying param
10-12 01:34:27.720 20734 20734 E PpssppActivity: Shortcut missing parameter!
10-12 01:34:27.723 20734 20734 D PPSSPPNativeActivity: Landscape: true
10-12 01:34:27.741 20734 20734 I PPSSPPNativeActivity: Setting requested rotation: 5 ('5') (Initialize)
10-12 01:34:27.795 20734 20734 I PPSSPPNativeActivity: OpenGL ES 3.0 detected.
10-12 01:34:27.820 20734 20734 I PPSSPPNativeActivity: Setting requested rotation: 5 ('5') (onCreate)
10-12 01:34:27.822 20734 20734 E PPSSPPNativeActivity: updateSystemUiVisibility: decor view not yet created, ignoring for now
10-12 01:34:27.824 20734 20734 I NativeSurfaceView: NativeSurfaceView
10-12 01:34:27.829 20734 20734 I PPSSPPNativeActivity: setcontentview before
10-12 01:34:27.832 20734 20734 I PPSSPPNativeActivity: setcontentview after
10-12 01:34:27.832 20734 20734 W PPSSPPNativeActivity: ensureRenderLoop - not starting thread, needs surface
10-12 01:34:27.835 20734 20734 I PPSSPPNativeActivity: Setting requested rotation: 5 ('5') (onResume)
10-12 01:34:27.835 20734 20734 I PPSSPPNativeActivity: onResume
10-12 01:34:27.851 20734 20734 W PPSSPPNativeActivity: ensureRenderLoop - not starting thread, needs surface
10-12 01:34:27.877 20734 20734 I PPSSPPNativeActivity: onPause
10-12 01:34:27.881 20734 20734 I PPSSPPNativeActivity: Joining render thread...
10-12 01:34:27.881 20734 20734 I PPSSPPNativeActivity: Joined render thread
10-12 01:34:27.881 20734 20734 I PPSSPPNativeActivity: onPause completed
10-12 01:34:27.881 20734 20734 I PPSSPPNativeActivity: onStop - do nothing special
10-12 01:34:27.881 20734 20734 I PPSSPPNativeActivity: onDestroy
10-12 01:34:27.886 20734 20734 E PpssppActivity: Got ACTION_VIEW without a valid uri, trying param
10-12 01:34:27.886 20734 20734 E PpssppActivity: Shortcut missing parameter!
10-12 01:34:27.888 20734 20734 I PPSSPPNativeActivity: Setting requested rotation: 5 ('5') (onCreate)
10-12 01:34:27.888 20734 20734 E PPSSPPNativeActivity: updateSystemUiVisibility: decor view not yet created, ignoring for now
10-12 01:34:27.888 20734 20734 I NativeSurfaceView: NativeSurfaceView
10-12 01:34:27.891 20734 20734 I PPSSPPNativeActivity: setcontentview before
10-12 01:34:27.893 20734 20734 I PPSSPPNativeActivity: setcontentview after
10-12 01:34:27.893 20734 20734 W PPSSPPNativeActivity: ensureRenderLoop - not starting thread, needs surface
10-12 01:34:27.894 20734 20734 I PPSSPPNativeActivity: Setting requested rotation: 5 ('5') (onResume)
10-12 01:34:27.894 20734 20734 I PPSSPPNativeActivity: onResume
10-12 01:34:27.904 20734 20734 W PPSSPPNativeActivity: ensureRenderLoop - not starting thread, needs surface
10-12 01:34:27.907 20734 20734 I PPSSPPNativeActivity: onAttachedToWindow
10-12 01:34:27.915 20734 20734 W PPSSPPNativeActivity: ensureRenderLoop: Starting thread
10-12 01:34:27.915 20734 28476 I PPSSPPNativeActivity: Starting the render loop: Surface(name=null)/@0xe65e55f
10-12 01:35:55.112 20734 20734 I PPSSPPNativeActivity: onPause
10-12 01:35:55.115 20734 20734 I PPSSPPNativeActivity: Joining render thread...
10-12 01:35:55.115 20734 20734 I PPSSPPNativeActivity: exitEGLRenderLoop
10-12 01:35:55.193 20734 28476 I PPSSPPNativeActivity: Left the render loop: Surface(name=null)/@0xe65e55f
10-12 01:35:55.196 20734 20734 I PPSSPPNativeActivity: joining render loop thread...
10-12 01:35:55.196 20734 20734 W PPSSPPNativeActivity: Joined render loop thread.
10-12 01:35:55.196 20734 20734 I PPSSPPNativeActivity: Joined render thread
10-12 01:35:55.196 20734 20734 I PPSSPPNativeActivity: onPause completed
10-12 01:35:57.986 20734 20734 I PPSSPPNativeActivity: Setting requested rotation: 5 ('5') (onResume)
10-12 01:35:57.997 20734 20734 I PPSSPPNativeActivity: onResume
10-12 01:35:58.031 20734 20734 W PPSSPPNativeActivity: ensureRenderLoop: Starting thread
10-12 01:35:58.032 20734 28939 I PPSSPPNativeActivity: Starting the render loop: Surface(name=null)/@0xe65e55f
10-12 01:36:30.550 20734 28970 I PPSSPP : [SCENET] !!! LocalHost IP will be 127.0.0.1 [ac:7e:39:c8:9a:99]
10-12 01:36:30.714 20734 28975 I PPSSPP : [G3D] !!! Loaded 3 vertex and 4 fragment shaders
10-12 01:36:30.714 20734 28975 I PPSSPP : [G3D] !!! Creating 8 pipelines...
10-12 01:36:30.739 20734 28975 I PPSSPP : [G3D] !!! Recreated Vulkan pipeline cache (8 pipelines).
10-12 01:36:30.744 20734 28939 I PPSSPP : [BOOT] !!! Loading /storage/emulated/0/PSP/Hitman Reborn Battle Arena 2 from UMD.ISO...
10-12 01:36:41.366 20734 28939 E PPSSPP : [SCEAUDIO] 80268002=sceAudioOutput2Reserve(2048): channel already reserved
10-12 01:36:42.973 20734 20734 I PPSSPPNativeActivity: Input player A registered: desc = fb60d4f4370f5dbe8267b63d38dea852987571ab
10-12 01:36:42.973 20734 20734 I InputDeviceState: Registering input device with 0 axes: qpnp_pon
10-12 01:36:42.973 20734 20734 I InputDeviceState: Vendor ID:0 productId: 0
10-12 01:36:43.391 20734 28939 E PPSSPP : [SCEAUDIO] 80268002=sceAudioOutput2Reserve(2048): channel already reserved
10-12 01:36:44.120 20734 20734 I PPSSPPNativeActivity: Input player B registered: desc = 485d69228e24f5e46da1598745890b214130dbc4
10-12 01:36:44.121 20734 20734 I InputDeviceState: Registering input device with 0 axes: gpio_keys
10-12 01:36:44.121 20734 20734 I InputDeviceState: Vendor ID:1 productId: 1
10-12 01:36:52.327 20734 28939 E PPSSPP : [SCEAUDIO] 80268002=sceAudioOutput2Reserve(2048): channel already reserved
10-12 01:37:14.315 20734 28939 E PPSSPP : [SCEAUDIO] 80268002=sceAudioOutput2Reserve(2048): channel already reserved
10-12 01:37:18.666 20734 28939 E PPSSPP : [SCEAUDIO] 80268002=sceAudioOutput2Reserve(2048): channel already reserved
10-12 01:37:29.761 20734 28939 E PPSSPP : [SCEAUDIO] 80268002=sceAudioOutput2Reserve(2048): channel already reserved

[somepunkid]

It crashed almost immediately in a match. Actually, let me be more specific, it freezes. The app stays open.

[hrydgard]

Oh, freezes... Yeah I wouldn't expect to see that in the log.

Gotten a lot of strange reports about freezes recently, that seems to be a separate issue.

[somepunkid]

Oh, freezes... Yeah I wouldn't expect to see that in the log.

Gotten a lot of strange reports about freezes recently, that seems to be a separate issue.

Ah! Very good. I've seen this audio log as well, on PC, but I'm sure that isn't anything important. Yes, this may be related to other freezing reports. My mistake with the terminology :>

[somepunkid]

Noting #13568 and #13200. Out of curiosity, are the small floating point differences impacting this issue also likely impacting these two?

[hrydgard]

The freezes should be solved now.

There are many other potential floating point differences, could be the same or different...

[somepunkid]

The freezes should be solved now.

There are many other potential floating point differences, could be the same or different...

Yes, I was going to confirm this. The game is stable on Android at this time.

[somepunkid]

Ah, set to compat for now eh? Had a feeling this might eventually impact other games...

[hrydgard]

Indeed.

I need to properly reverse engineer these functions in detail it seems. For now, this will work.

[unknownbrackets]

Some initial notes on the PSP vfpu sine:

• Any inf/nan input produces a NAN of the same sign (i.e. 0x7F800001.)
• Inputs with an exponent below 0x68 (-23) are treated the same as zero, regardless of mantissa.
• Inputs with an exponent above 0x9F (32) are treated as if the exponent is subtracted off without affecting the mantissa (I suspect as part of the modulus by 4, it performs a shift and does this only by & 0x1F maybe?)
• The produced mantissa never appears to have the lower 2 bits set.
• When the input exponent is 0x68, the lower 18 bits are not set. This reduces by one bit for every exponent until 0x78, when he lower 2 bits are not set (as for all following exponents.)
• So far I have not seen a result produce an exponent lower than 0x68 (-23) and obviously 0x7F (0) is the highest possible exponent.
• I'm thinking it might just use cordic after normalizing?

-[Unknown]

[unknownbrackets]

Messing with the cordic a bit more, it does seem promising but I'm not sure what precision and rounding the hardware would be using for the table and iterations. Or the number of iterations. Took some initial guesses.

With that and a simple modulo implemented on the integer side, I produced a range of example values (mostly different exponents with a few tricky mantissa values) and compared the different methods. This is for bit exactness:

fmodf + sinf = 435 / 794
floorf + sinf = 439 / 794
sin (fmod or not) = 449 / 794
custom modulo + sinf = 451 / 794
custom modulo + cordic = 475 / 794
custom modulo + sin = 479 / 794
sin + mask last 2 bits = 504 / 794
custom modulo + cordic + mask last 2 bits = 517 / 794
custom modulo + sin + mask last 2 bits = 654 / 794

I guess I'm doing too little accuracy based on the last sin result (or maybe it's not cordic...), but it does seem like the modulo has had positive results.

-[Unknown]

[hrydgard]

Cool investigation! Last option seems promising. Is there any pattern to the off bits?

Might it be linearly interpolating a lookup table? in that case you'd see the error oscillate as you walk along the curve. Although it could of course be doing higher order interpolation too.

Might also be interesting to sum up the bits that are off - I assume some are off by more than one bit? Also, are there any sign errors left with any of the inputs? I think it's likely that some problems with this games are because of sign issues caused by the modulo being slightly off...

[unknownbrackets]

Hmm. I could see it correcting errors with a lerp from the taylor or cordic output to a table or something. I guess I need to graph more values to be sure.

The sign is always right, at least with my modulo checks in place.

Some examples:

• 54FFFFFF (8796092497920) results in -0.000192
  VFPU calculates B9491000, but sin calculates B9490FD8
  CORDIC (22 iterations, 32 bits of fixed point precision) calculates B9490D00, 32 iter = B9491000 (correct)

• 37012345 (0.000008) results in 0.000012
  VFPU calculates 37490000, but sin calculates 374AD960
  CORDIC calculates 3750D000 @ 22, 374AE000 @ 32

• C0012345 (-2.017778) results in 0.027921
  VFPU calculates 3CE4BBA0, but sin calculates 3CE4BB98
  CORDIC calculates 3CE4BBC0 @ 22, 3CE4BB98 @ 32

• 44400009 (768.000549) results in 000863
  VFPU calculates 3A623240, but sin calculates 3A6231D4
  CORDIC calculates 3A624340 @ 22, 3A6231E0 @ 32

It's not really any consistent bits that are always wrong or anything. I suspect it's more down to what approximation method it uses, and what the atan table / polynomials / etc. are...

-[Unknown]

[unknownbrackets]

Did a little more testing and looking at mismatching values. New finding (added above too):

• When the input exponent is 0x68, the lower 18 bits are not set. This reduces by one bit for every exponent until 0x78, when he lower 2 bits are not set (as for all following exponents.)

This is probably more about the output exponent though, just looked at input since it was easier. I assume this is about the fixed point space in which the result is calculated.

I dumped all mantissa values (and results) for a few useful ranges of exponents and compared some across the several gigabytes of data. On this result set, about 58% match with modulo preprocess + double sin + 2 bit postprocess (preprocess and postprocess improve it from around 10%.) The set has a chunk of those lower exponents, and just dumbly applying that rule increases to around 70% or so (sorry might've accidentaly applied to a subset - it's still true, but doesn't seem to help quite that much.)

Not sure how important those bits not being set is in practice.

Confirmed signs match in 100% of those ~220 million dumped cases, including zeros, inf/nan, subnormals, etc. And also that the lower 2 bits are never set (except NAN and -NAN results, mportantly.)

-[Unknown]

[somepunkid]

Let me know if any variable changes are applied and need to be tested versus the game to see if it resolves it's current issue!