Game: Tales of Xillia 2 BLUS31397
PPU: LLVM Recompiler
SPU: ASMJIT Recompiler
GPU: Vulkan
Version: #5229 (83b6c985)
Using the above settings, overworld animations play at 2x speed. This leads to the character (and monsters) running around at ludicrous speed, as well as cutscenes progressing before the characters have finished saying their lines.
Attempted to fix by:
Using OpenGL renderer makes the issue go away, however half the textures are missing in OpenGL (probably a separate issue).
Forcing Strict Rendering causes a crash after the Bandai-Namco splash screen.
Game Log shows:
E {PPU[0x1000000] Thread (main_thread) [0x0121ff0c]} '_sys_prx_get_module_id_by_name' failed with 0x8001112e : CELL_PRX_ERROR_UNKNOWN_MODULE [1]
E {rsx::thread} RSX: NV3089_IMAGE_IN_SIZE: Invalid blit dimensions passed
E {PPU[0x1000000] Thread (main_thread) [0x0081b9a0]} 'sys_ppu_thread_detach' failed with 0x80010005 : CELL_ESRCH [1]
E {PPU[0x1000000] Thread (main_thread) [0x0081b9d4]} 'sys_ppu_thread_join' failed with 0x80010005 : CELL_ESRCH [1]
E {PPU[0x1000000] Thread (main_thread) [0x0081b9a0]} 'sys_ppu_thread_detach' failed with 0x80010005 : CELL_ESRCH [2]
E {PPU[0x1000000] Thread (main_thread) [0x012e1ee4]} 'sys_fs_stat' failed with 0x80010006 : CELL_ENOENT, “/dev_hdd0/game/BLUS31397_INSTALL/USRDIR/FILEDATABASELOCAL.TLFDBX” [1]
E {PPU[0x1000000] Thread (main_thread) [0x0121ff0c]} '_sys_prx_get_module_id_by_name' failed with 0x8001112e : CELL_PRX_ERROR_UNKNOWN_MODULE [2]
E {PPU[0x1000000] Thread (main_thread) [0x0081b9a0]} 'sys_ppu_thread_detach' failed with 0x80010002 : CELL_EINVAL [1]
E {PPU[0x100000e] Thread (CThread) [0x0081bb58]} sceNpTrophy: sceNpTrophyRegisterContext(context=0x1, handle=0x1, statusCb=*0x108cb00, arg=*0x0, options=0x0)
E {PPU[0x1000000] Thread (main_thread) [0x0081b9d4]} 'sys_ppu_thread_join' failed with 0x80010005 : CELL_ESRCH [2]
E {PPU[0x1000000] Thread (main_thread) [0x0081b9a0]} 'sys_ppu_thread_detach' failed with 0x80010005 : CELL_ESRCH [3]
E {PPU[0x1000000] Thread (main_thread) [0x00994ce8]} 'sys_ppu_thread_set_priority' failed with 0x80010005 : CELL_ESRCH [1]
E {PPU[0x1000000] Thread (main_thread) [0x0081b9d4]} 'sys_ppu_thread_join' failed with 0x80010005 : CELL_ESRCH [3]
E {PPU[0x1000000] Thread (main_thread) [0x00994ce8]} 'sys_ppu_thread_set_priority' failed with 0x80010005 : CELL_ESRCH [2]
E {PPU[0x1000000] Thread (main_thread) [0x00994ce8]} 'sys_ppu_thread_set_priority' failed with 0x80010005 : CELL_ESRCH [3]
E {PPU[0x1000000] Thread (main_thread)} Stat: 'sys_ppu_thread_detach' failed with 0x80010005 : CELL_ESRCH [x4]
E {PPU[0x1000000] Thread (main_thread)} Stat: 'sys_ppu_thread_set_priority' failed with 0x80010005 : CELL_ESRCH [x14]
Okay. More info. Setting the frame rate limiter to 30 FPS fixes cutscenes, however it makes combat sluggish. Looks like the game might do 30FPS in the overworld and 60FPS in combat?
Is there any way to get RPCS3 to detect the intended frame rate?
There's a hacky fix made by Durante (https://github.com/PeterTh/rpcs3/commit/b569b32da53f2626cb622df1dcf2ce4d2010b02c) that allows switching between 30/60 FPS while the emulator is running. Can this be merged in and bound to a hotkey?
Duplicate of #5114.
Duplicate of #5114.
It's more #5114 + ability to bind settings changes to hotkeys.
Try setting framerate limiter to "Auto". Probably will help switching between 30 and 60 on a single run.
Try setting framerate limiter to "Auto". Probably will help switching between 30 and 60 on a single run.
That was my first thought but no dice. The game runs at 60FPS on Auto, so we end up with truncated cutscenes and Yakety Sax animations. My guess as to how Auto works is some sort of heuristic that attempts to find out the frame rate when the game boots, but since config paramaters can't be updated while the emulator is running (As per #5114), even if Auto did correctly figure out when to switch frame rates, it wouldn't be able to.
So the actual issue here is that Auto doesn't work as it should, and the solution would be to make it listen and obey refresh rate changes coming from the game. Adding support to arbitary setting changes on the fly would be an useful feature but not required to fix the issue with this game.
So the actual issue here is that Auto doesn't work as it should, and the solution would be to make it listen and obey refresh rate changes coming from the game. Adding support to arbitary setting changes on the fly would be an useful feature but not required to fix the issue with this game.
Right. It's worth noting that the same issue exists with Tales of Xillia 1. In reality the fix for this is a lot smaller in scope than #5114, however this issue is a prerequisite for that one.
And Tales of Graces F.
This is a problem I reported a year and a half ago on the "Tales" of" game, the RPCS3 auto FPS does not seem to work properly on these games. Having an option to go from 60 to 30 FPS with hotkey would obviously be convenient but it will be a workaround, not a solution.
The real problem is that RPCS3 has trouble seeing the changes requested from framerate on these games and it's a bug.
Using Bandicam or any other external FPS limiter is untenable, it causes stuttering and frame skipping, the fps clamp has to come from within the process.
I know that hacks like OP is requesting are looked down upon poorly and for good reason. But i would suggest a workaround for the moment, and only if no one is actively working on a solution for the auto framerate issue found, apparently, only in a handful of titles.
Setting up a hotkey for 60 to 30 fps limiting, hiding it away in the dev options and once or if a turbo functionality is implemented, using the same hotkey for the turbo function. I don't think it's a great solution but it would at least have a depreciated purpose to exist.
edit: reading #5114 , the implication is that fps cannot be changed without a restart of the main program. if that's true, that makes this request and my suggestion irrelevant since adjusting auto fps on the fly would probably result in fixing the underlying issue entirely making a hotkey unnecessary.
@Marthgun Not really. Changing operating parameters (such as the renderer) isn't current possible with the game running. The hack I linked (https://github.com/PeterTh/rpcs3/commit/b569b32da53f2626cb622df1dcf2ce4d2010b02c) allows you to change FPS. I'm unsure if it's implemented using the built-in FPS limiter, or a new implementation, however, usually, the FPS limiter isn't actually part of the renderer, it just ensures the renderer outputs a frame as close as possible to X milliseconds (33.34ms for 30 FPS, 16.67ms for 60 FPS). So long as the frame limiter is making a check against some timing variable, you could change that timing variable while the limiter is running. That should allow you to change the target frame rate on the fly.
A contributor can probably advise if I'm talking out of my ass here, but I'm still trying to digest how Durante's hack works so I can attempt to do just that. The only difficulty then would be detecting when the game wants you to change the FPS target.
That would allow this to not be a "hack" to get certain games to work, but instead a "feature". Specifically, having Auto FPS limiter do what you (read: I) expect it to.
@Diserasta I'm pretty sure Durante does his stuff by injecting into the render stream, which is not something you'd want to do since we have the source code available.
I checked your link to Peter's branch and I didn't see anything related to changing fps via a hotkey. I did get curious and checked the code, the Auto function in the Master is not working at all. it's actually set to 59.94 via the fps_limit variable in RSX_Thread.h.
I was, wrongly, under the impression Auto framerate was working in other games, but it looks like that's not the case, unless this is handled somewhere else, and idk why it would be. As far as changing the value while the main program is running, i wouldn't have any idea how to do that. Whatever information the game is sending out to switch between frame rates is probably not being handled if it's even been deciphered yet. checking some frame captures between gameplay and skits in Tales of Graces might yield something if you knew what you were looking for. unfortunately I don't.
So far as I understand the hack, the key isn't bindable by the user, it's bound to XInput Left Stick Click in the source code, so that's probably what to search for, though I have yet to find exactly where in the code this happens.
Though you bring up an interesting point. If fps_limit is set in RSX_Thread.h, it might be feasible to expose that variable and change it on the fly. I'm currently wrangling my Windows to get all the dependencies fixed, and I'll try making a custom build with FPS limit exposed. That should be step one.
actually setting the hotkey is going to be one of the hardest parts, trying to follow what they're doing on the gui side is very difficult. I was looking at this awhile back and the bindings for one were in something like half a dozen files. I couldn't really follow it. also, the rsx thread may only be initialized once, which would make changing that value irrelevant. I'm not exactly sure how it works, or if there are other places where it pulls fps values from.
also, just a thought, there may not be any auto fps switch, it could just be native ps3 is handling different file types differently. the skits in tales of graces are pre-rendered as far as I could tell with render doc.
Bumping this, even if the games got fixed, i think a FPS toggle button / hotkey would be extremely helpful. can we please get someone in on implementing this? i feel like it's pretty overdue feature.
Just as a heads up, I re-implemented Durante's fix on my fork based on latest master. Here's the build for anyone that may be interested. I didn't add anything else to it (and probably won't add anything either) https://ci.appveyor.com/api/buildjobs/131j29dje6hq8hut/artifacts/rpcs3-v0.0.6-7888-f966094a_win64.7z
Created an issue on my fork to track this build: https://github.com/RainbowCookie32/rpcs3/issues/1 go spam there as much as you want
Thanks for the build(I almost clear the ToX1 with no problems at all(not a single crash))but there is one problem.
If you are not using XInput controller,the hotkey will not work and the hotkey is binded to a button detected by xinput as L3,not to what you set the L3 to be in the Input settings(I tried changing L3 to the home button on my gamepad but is still switching speeds with L3)
Yep, I'm aware of that. The keybind for toggling is hardcoded to L3 (I accept suggestions for what could be a better button), and only works on XInput. I'm currently testing the implementation on MMJoystick and will move to the other Pad handlers if successful. To reduce notification spam, I'll update this comment with new builds if/when they are ready.
There is something strange tho...when I am playing in the coliseum for example,30fps sometimes feel like normal speed,it's not slow at all(30fps internal speed at 60fps refresh rate)and when I switch to 60fps,the game becomes as smooth as playing at 60fps internal speed(twice as smooth not twice faster)
Outside of battle at 30fps,30fps is normal internal speed and at 60fps,it is running at 30fps internal speed but the game is running twice as fast(like playing at 120fps a PS2 game on pcsx2)
For this game at least L3 is the best button because the game is not using it for anything
Edit:Actually it is,it is used for taunting(which I never do)
@vsub thats because the tales games (actually alot of ps3 games to be fair) don't always run at the same FPS. for example in graces F, running around is 30 FPS but menus are 60FPS. same in eternal sonata. also, xillia battles are supposed to be 60FPS.
so, games can do animations one of two ways. they can lock animation to FPS for example, a spell takes 15 frames to cast, then 15 frames of a hurtbox for damage. almost every gba game has animations being timed to frames. however the other way, is to tie animation to time, such as a spell has a 0.5 second channel time, and then casts. The first case is Animation tied to FPS, the second is Animation tied to Time (I'll call these AFPS and TFPS)
TFPS can be seen in Mobas alot, league of legends, heroes of the storm, smite, Dota2, and so forth. in these games you can have unlimited FPS, because FPS doesn't affect game speed, it just affects how smoothe things run at.
AFPS can be seen alot in JRPGS, games like kingdom hearts, earthbound, pokemon, persona 5, ect. AFPS lets developers decide exactly how something will look to everyone, and is used alot on console rpgs.
Now Xillia, it uses AFPS in menus and while walking around, so x2 fps means you run double speed, but TFPS in battle, meaning the game just runs more/less smoother in battle based on the FPS.
whats strange is tales of Graces F. it's battles are supposed to be 60FPS, but they run at 30FPS in RPCS3. however it uses AFPS in graces F battles, so if you double it to 60, rather then running smoother as intended, it runs at double speed instead. i've been told Graces F battles being at 30 is a bug caused by rpcs3, but i don't know if anyone is looking into it.
another example, is skits in graces F are 60AFPS, so you have to be at 60 when they start or they get out of sync, but running around (much like xillia) is 30AFPS, so you need to use this build that lets you swap fps with the L3 button because again, due to whatever bug, rpcs3 doesn't auto switch it's FPS when a skit happens, so it looks all out of sync between voices and mouth movements.
so, for games that use TFPS and run at 30, this hack lets you run the game way smoother then on a real FPS, and games that use AFPS and run at 30, this hack lets you play at x2 speed if you want.
well, technically you could do that even without the the L3 build, but it lets you toggle it. good for games where auto is either not changeing correctly, or games where you want to run at 60fps in specific situations.
Seems that feature is added by https://github.com/RPCS3/rpcs3/pull/7723 but there is no hotkey
I don't know if that feature is needed anymore as a fix because if you set the vbalnk to 30 and the fps limit to 50(for PAL)60off,the game will running at proper speed everywhere(in and out of battle)
Closed as implemented, limiter is already modifiable while in-game