-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ULJS00218 - Hitman Reborn Battle Arena 2 - Player 2 side broken/reversed/broken kick animation #12900
Comments
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 |
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... |
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. |
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: 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] |
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. 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. 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. |
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. |
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. |
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): -[Unknown] |
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 |
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. |
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. |
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:
Not sure what else... -[Unknown] |
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? |
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... |
Right, okay. Really running out of ideas here... |
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. |
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? |
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 :) |
Heh. It was the wrong link, corrected it. Found the build here, just had an issue with my browser. Disregard that. |
You can download v0.9.8 here: At least the stable releases from back then are available there: 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] |
I've confirmed v0.9.8 works with default settings. I will continue testing revisions. |
Cool! Seems we got lucky here that it worked back then - can't wait to see what caused this... |
I did not mean to close this. Damn mobile buttons |
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. |
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 :> |
If you install the Android SDK, you get a command line tool called
(The long parameter list is to filter only PPSSPP-related stuff). |
Done: Log --------- beginning of crash |
It crashed almost immediately in a match. Actually, let me be more specific, it freezes. The app stays open. |
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 :> |
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. |
Ah, set to compat for now eh? Had a feeling this might eventually impact other games... |
Indeed. I need to properly reverse engineer these functions in detail it seems. For now, this will work. |
Some initial notes on the PSP vfpu sine:
-[Unknown] |
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 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] |
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... |
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:
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] |
Did a little more testing and looking at mismatching values. New finding (added above too):
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 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] |
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! |
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.
The text was updated successfully, but these errors were encountered: