ULJS00218 - Hitman Reborn Battle Arena 2 - Adhoc performance issues after latest test build

[somepunkid]

Reporting a major performance regression in Adhoc on v1.10.3-1044-ga4a0b4ba0
Game -ULJS00218 - Hitman Reborn Battle Arena 2
VID: https://youtu.be/LzogWD5YW7Q (watch the frame counter, primarily. Left - few dips, right -lots of dips)

Performance differences between this build and the previous release build v1.10.3-1026-g36a614072. Fluctuates between 50-55 frames in menu in games, randomly dipping higher and lower. Tested on multiple previously stable systems/configs. Locks to 60 and then dips between rounds/in game. Just in general, everything is slower/chunkier in adhoc mode only now. The base game is fine outside of adhoc.

This game still requires the "force real clock sync" option to lock to 60 in adhoc play. Otherwise, no other default setting was changed besides network settings to allow connection.

This was contrasted directly to the previous build on the same machine (2 instances, same machine, see vid). This takes input buffer into consideration, so yes, there will be desyncs caused by this in the video (using a 360 stick). What should be watched is the FPS marker.

EDIT: Added vid. Tested using both instances on same machine for visible differences, set all to 1x resolution. It's possible the newer instance started running slightly better in game after first boot/use/texture loads? Either way, even with this, seems to be a really big difference in menus/screen transitions, and sometimes in the form of dropped frames in game. This was running rock solid 60 in most instances, previously, with an occasional small dip between screens.

There is no english patch, sadly. Option 3 on the main menu leads to 1p vs 2p(adhoc), which should be easy to navigate from there for testing

They are both using "Force real clock sync" in the video test, as the game won't run correctly any other way.
If this option is not selected, this game defaults to slow framerates as soon as the fight starts, it will cap at 30fps. Force clock sync allows it to run correctly/at 60fps. This game has only worked with this option enabled, in adhoc. It works both ways outside of adhoc.

If I disabled force clock sync, as soon as a player is in a match, gameplay slows to a crawl, regardless of the ppsspp version.(in adhoc)

Regardless of this, it still runs great/consistent 60fps on previous builds with force clock sync enabled, even on less capable hardware (tablets/surface tested) so this hasnt been an issue.

ADDED NOTES FROM CHANGE #13579 that changed this games performance.

ANR2ME

Ugh Hitman Reborn Battle Arena 2 is using the smallest timeout i have ever seen so far :( and it's abit tricky to fix it.
This game only use 2 SCENET function during battle, sceNetAdhocPdpSend and sceNetAdhocPdpRecv both with blocking mode.

One of the problem was what happen to the PdpRecv, it using 50 usec timeout, and when there are no data available to be received it enters blocking simulation and the timeout were overriden by the minimum timeout workaround (which is defaulted to 1 ms or 1000 usec) so it's taking too much time to hit the timeout.
I tried changing the minimum timeout to 0 but based on this test, there are times where the interval (Timestamp Delta) goes nearly 1ms between each reScheduled Event :( So there might be FPS drops during this long delays.

PS: when the game runs 60 FPS each PdpRecv calls never (or very rare) enter blocking simulation because for some reason there is always data ready to be received (might be just by luck that both side were in sync when sending and receiving data?), so it can receive and return immediately.

Other than this, there should be more issue during lobby/character selection, probably related to hleEatMicro i added in some functions.

Btw, @somepunkid could you open an new issue for this?

Originally posted by @anr2me in #13579 (comment)

[anr2me]

Okay, i found the main culprit for the major FPS drops, it's because of hleEatMicro within sceNetAdhocctlGetPeerInfo function.
We don't have an accurate networking API delays because nobody benchmarking them :D

[somepunkid]

Okay, i found the main culprit for the major FPS drops, it's because of hleEatMicro within sceNetAdhocctlGetPeerInfo function.
We don't have an accurate API delays because nobody benchmarking them :D

Glad this was found! If any testing is required, I can assist with this!

[anr2me]

Try again after PR #13606 got merged later.
You may also want to change Minimum Timeout setting to 0 to reduce extra delays further.

[somepunkid]

Try again after PR #13606 got merged later.
You may also want to change Minimum Timeout setting to 0 to reduce extra delays further.

Tested these #13606 changes vs v1.10.3-1026-g36a614072 Minimum Timeout settings are at 0.

This is much more functional/faster between menus, during character intro transitions, and in game. The latest revision still chugs behind in menu transitions and now very rarely during character intro transitions, but overall recovers much quicker than it did.

Still slightly slower, but much, much better than previously and definitely plays good. Didn't notice any major frame drops in game.

[anr2me]

Probably because i only changed the hleEatMicro from 1000 to 100 within sceNetAdhocctlGetPeerInfo so there is still 100 usec delay while v1.10.3-1026-g36a614072 doesn't have delays at all.
Not sure how much delay a real PSP should take on this function since nobody ever benchmarking it, but @adenovan might try to benchmarks it sometimes in the future, i guess it should be lower than 100 usec if you still noticed the difference (i honestly can't tell the FPS difference when comparing them LOL), i'll probably lowered it again in the future.

[somepunkid]

Probably because i only changed the hleEatMicro from 1000 to 100 within sceNetAdhocctlGetPeerInfo so there is still 100 usec delay while v1.10.3-1026-g36a614072 doesn't have delays at all.
Not sure how much delay a real PSP should take on this function since nobody ever benchmarking it, but @adenovan might try to benchmarks it sometimes in the future, i guess it should be lower than 100 usec if you still noticed the difference (i honestly can't tell the FPS difference when comparing them LOL), i'll probably lowered it again in the future.

Yeah, I did the testing just as before, running the previous build and this at the exact same time. It is an impact/not optimal, but doesn't seem to hit gameplay too much after the round starts. Still, the menu transition difference is much more noticeable/significant, but this ONLY applies when going from the winning results screen after a match, back to the character select screen. It's very noticeable here still, primarily, but still not quite as bad as when this first got changed. It still works!

[somepunkid]

I'm mostly referencing this exact moment: https://youtu.be/LzogWD5YW7Q?t=278

That would be the only place the average user would notice a difference LOL. This still applies in the latest build. The only reason I even see it is because of how often it's played/tested with other users offline, on the same screen (VS mode with sticks etc)

Once again, I've not yet noticed a gameplay difference once a match is moving...but I've not stress tested with two users yet either moving actively/producing effects etc. Eh, I'll just update this if it get worse or something :>

[ghost]

You most likely use Parsec to play the game online right? it uses lockstep like other fighting games I know of .

[somepunkid]

You most likely use Parsec to play the game online right? it uses lockstep like other fighting games I know of .

This game is played offline in my groups, using the same laptop with two instances of PPSSPP launched, to replicate a "normal" offline VS mode over adhoc. We use it with Parsec as well for online play, and that works great, so I'm not sure what it's Online/VPN performance is even like!