Skip to content
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

Closed
somepunkid opened this issue May 15, 2020 · 118 comments · Fixed by #14406
Closed
Milestone

Comments

@somepunkid
Copy link

somepunkid commented May 15, 2020

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
Copy link
Owner

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?

@hrydgard hrydgard added this to the Future milestone May 15, 2020
@somepunkid
Copy link
Author

somepunkid commented May 15, 2020

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
Copy link
Owner

Thanks for testing that!

@somepunkid
Copy link
Author

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
Copy link
Owner

hrydgard commented May 15, 2020

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

somepunkid commented May 16, 2020

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
Copy link
Author

somepunkid commented May 16, 2020

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

somepunkid commented May 19, 2020

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
Copy link
Owner

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
Copy link
Author

somepunkid commented May 19, 2020

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
Copy link
Owner

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

@somepunkid
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

somepunkid commented May 19, 2020

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
Copy link
Owner

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

@somepunkid
Copy link
Author

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
Copy link
Author

somepunkid commented May 20, 2020

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
Copy link
Owner

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
Copy link
Author

somepunkid commented May 20, 2020

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

@unknownbrackets
Copy link
Collaborator

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
Copy link
Author

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

@hrydgard
Copy link
Owner

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

@somepunkid
Copy link
Author

I did not mean to close this. Damn mobile buttons

@somepunkid
Copy link
Author

somepunkid commented Oct 11, 2020

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

hrydgard commented Oct 12, 2020

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
Copy link
Author

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
Copy link
Author

somepunkid commented Oct 12, 2020

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

@hrydgard
Copy link
Owner

hrydgard commented Oct 12, 2020

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
Copy link
Author

somepunkid commented Oct 12, 2020

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 somepunkid changed the title ULJS00218 - Hitman Reborn Battle Arena 2 - Player 2 side broken/reversed ULJS00218 - Hitman Reborn Battle Arena 2 - Player 2 side broken/reversed/broken kick animation Oct 27, 2020
@somepunkid
Copy link
Author

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

@hrydgard
Copy link
Owner

The freezes should be solved now.

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

@somepunkid
Copy link
Author

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
Copy link
Author

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

@hrydgard
Copy link
Owner

Indeed.

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

@unknownbrackets
Copy link
Collaborator

unknownbrackets commented Apr 18, 2021

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
Copy link
Collaborator

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
Copy link
Owner

hrydgard commented Apr 18, 2021

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
Copy link
Collaborator

unknownbrackets commented Apr 18, 2021

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
Copy link
Collaborator

unknownbrackets commented Apr 19, 2021

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
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants