hrydgard
Brothers in Arms: D-Day - slow gameplay
https://github.com/hrydgard/ppsspp/assets/130929/a9926168-914d-42c1-ae09-1c4569d5e8b8
penderfender.objectivebutter on Discord reports that gameplay in Brothers in Arms: D-Day is running weirdly slowly compared to on the real hardware. It sure looks lke in the video, PSP on top, PPSSPP on the bottom.
Movement Speed for this game is tied to frame rate.
Movement speed is slow if the game is running at 60 FPS: https://streamable.com/hqrreo
The Moving Speed is okay if running at 30 FPS using underclocks: https://streamable.com/ip4lov
Hm, interesting. Maybe we should just lock framerate to 30hz similarly to how we lock God of War to 60hz.
If you put the ID under [GoWFramerateHack30] in assets/compat.ini, is it better? Do menus break or slow down or something?
Those GOW hacks are via function replacements since it worked better than the old method and worked around game bug, unlikely to affect different games. We'd need an alt version of ForceMax60FPS for more universal approach.
There's a secondary issue here althrough probably caused by same/similar thing. The game's often is running under 100% even if hardware can is more than capable running it in hundreads of FPS. Looked at it and it's using sceKernelGetSystemTimeLow twice every frame, probably uses this time to decide how it should run. Maybe it doesn't eat enough cycles?
Edit: making sceKernelGetSystemTimeLow to eat absurdly high cycle count makes it run faster while keeping 60 fps, but there's still some instability which drops under 100% casually so maybe it's some other syscall.
Edit2: adding hleEatCycles(added a lot just to test) to scePowerGetCpuClockFrequencyInt seems to solve both the strange instability and speed while keeping 60 fps. Seems it doesn't even need to eat a lot of cycles, my first test was like 100000, my second test was 2000 and it still ran perfectly fine.
I believe checking if and how much scePowerGetCpuClockFrequencyInt eats cycles on real hardware would be a way to fix this, otherwise a compat hack that makes it eat 200 cycles would be fine. (That's just the third value I tested, not sure how little would be enough.)
Edit: ~huh dunno what happened, seems like small values doesn't work anymore, I was copying exe from my build folder to one I keep ppsspp normally, need to spend more time on this.~ ~nvm it does work, but fps aren't holding 60, they were for me earlier as in the copy I usually run ppsspp from I overclocked PSP CPU trying to see if it helps with instability. And as an obvious side effect it made it run at full 60 fps when stability got corrected with the change above.~
Edit2: actually wrong again, either this game seems to randomly missbehaves in my system or I'm confused by OC PSP CPU not being updated instantly as that appears to be the only thing needed to make it run both stable and at normal speed, it needs to be at least like 2x of real PSP clocks, so it might be bad for mobile users.
I'm tired, but retested initial finding with adding cycles eat to sceKernelGetSystemTimeLow and making sure I restarted whole ppsspp after switching back cpu clock to auto and that seems to work, probably even makes the game a bit lighter when set to crazy high values like 100165(yeah I just added 100k to initial value). While testing I also noticed some regression in graphics during initial loading screen in this game in latest PPSSPP will try to check what exactly broke it before I go to sleep, it should be something fairy recent as my local source was max just a few weeks old.
Another game affected by high frame rate issue is Blitz: Overtime which runs too fast if running at 60 FPS.
Blitz: Overtime
Unless we want to collect all issues caused by "PPSSPP running too fast" in here, it probably should get it's own issue. A workaround exist for it.
Blitz: Overtime
Unless we want to collect all issues caused by "PPSSPP running too fast" in here, it probably should get it's own issue. A workaround exist for it.
FPS Fix caps the frame rate to 30 FPS, But how about Syphon Filter games? It has CPU emulation bugs due to possibly tied to frame rate?
Those problems aren't caused by framerate even through framerate can be affected by the problem. It's all about various functions taking wrong time and games being poorly coded to depend on it, also syphon filter is pretty much the same as resistance retribution and they have separate issues.
