Possible regression for Persona Q2

On Nightly 1883, Persona Q2 regularly experiences lock-ups during dialogue and combat and occasionally drops from a stable 30 FPS to an average 0.5 FPS, requiring a reset to fix. These issues are absent on Nightly 1272, and, according to someone in this GitHub Issue, they’re also absent in Nightly 1675. This also seems to happen regardless of game region, though I found that the Japanese version broke before I could even get past the main menu.

I apologize if this is inappropriate for “Citra Support” topics, I thought this didn’t exactly fit in “General”.

System Information

  • Operating System: Windows 10
  • CPU: Intel(R) Core™ i5-7300HQ CPU @ 2.50GHz
  • GPU: NVIDIA GeForce GTX 1050
  • Citra Version: Nightly 1883
  • Game: Persona Q2

In order for us to provide better support, we need to see the log generated by citra. This guide will walk you through how you can obtain the log file: How to Upload the Log File

First of all, please upload a log file using the guide that the bot posted above.

Here’s a log from Nightly 1883 where the game locks up mid-dialogue after about 25 minutes:
citra_log.txt (61.4 KB)

Nothing in the log file is standing out to me. If this is indeed a regression, figuring out when exactly this issue started occurring would be very helpful in figuring out why this is happening for the developers.

If you have some time available, we’d appreciate it if you could help with testing. Essentially, what you’d have to do is this:
([Earliest known build with the issue] + [Latest known build without the issue]) / 2
So from your opening message, that would be:
(1883+1675)/2 = 1779
So Nightly 1779 needs testing.

The results will change either [Earliest known build with the issue] or [Latest known build without the issue]. Keep testing until you have 2 builds side by side in which one has the issue, and the other does not.

Took a bit, but I’ve done the tests, all with the same ROM. In short, I’ve narrowed it down to 1805 as the latest “stable” version and 1806 as the earliest “bugged” version.

Since it seems to be somewhat random, I’ve played the game for about an hour on each version. If I found one of the relevant issues, I’d stop emulation then close Citra as soon as possible to get the log.

Hmm, the only change from Nightly 1805 to Nightly 1806 appears to be CMake: Update Qt bundle for Visual Studio 2019/2022 by ameerj · Pull Request #6176 · citra-emu/citra · GitHub
Would be a bit strange if a change like that caused an issue like this ngl.

Well, If I were you, I’d post about your findings on the GitHub issue, and perhaps ping the other users who reported the same issue with your comment so that they can test your findings for themselves and see if they can reproduce the same results.

I use Citra Nightly version 1805 and have battle lock-up after play 1 hour here file log
citra_log.txt (61.2 KB)

I’m back, been busy with IRL stuff.

Looks like I didn’t play 1805 long enough, then. Hopefully I didn’t miss 1779 as well.

I went ahead and tested 1792; ran into the same lock-up as 1811.
citra_log.txt (23.5 KB)

have you test Citra Nightly version 1819 to version 1829 yet

Of note: these battle lock-ups also seem to be preceded by missing assets, but it’s harder to notice since it only affects the Persona screen, which I personally rarely use.

We won’t be testing for these issues in any versions later than 1785. Since I already found that 1785 contains the same issues the others do, we would just be reaching redundant conclusions.

To clarify the method, just in case:

It’s inefficient to test each and every individual version, which is why I’m following this suggestion:

This saves us from having to test each individual version by cutting the range we have to search in half each time we reach a conclusion. It’s called a “binary search” if you’re curious, but that’s beside the point.

Since I now know that 1785 also has issues emulating PQ2, then the next version to test is 1782, because the average between 1785 and 1779 (which is the latest version number where no issues were observed) is 1782. We can draw one of two conclusions after testing:

  • If 1782 does not have issues emulating PQ2, that would make it the [Latest known build without the issue]. We then would test 1783, since it’s the average between 1785 and 1782.
  • If 1782 has issues emulating PQ2, that would make it the [Earliest known build with the issue]. We then would test 1780, since it’s the average between 1779 and 1782 (after rounding down to an integer).

TL;DR: We test 1782, do some math, test whatever version the math gives us, and repeat until we get two versions side-by-side.

i test 1782 and it seem softlock during open the door but it weird when test 1782 first time it didn’t softlock during first boss battle and random battle so i don’t know what happen

Well, this is weird. I haven’t seen the game lock-up while opening a door yet. Some of them have dialogue triggers, which can lead to a lock-up, but it’s always placed immediately before or after interacting with the door. If it happened during the door opening animation and fade out, it could be a loading issue, since doors in PQ2 also serve to hide asset loading and pop-in.

This lines up with what I’ve seen on my end. No signs of any issues throughout the second dungeon and first floor of the third dungeon, including all the necessary fusions and some Special Screenings.

I’m inclined to mark 1782 as OK for now, but it’s the first version we should try again if it doesn’t lead us anywhere.

Nightly 1782-1783 would be more logical. Since in 1783, a big graphical PR got merged, which had a couple regressions at the time. Though, I’d rather be sure before bothering the dev about it.

  • 1783: Dialogue sequence lock-up, preceded by missing images in menus.

Sounds like we got to the correct version this time around then, but I’ll put some more time on 1782 just in case.

  • 1782: Dialogue sequence lock-up, preceded by missing images in menus.

Looks like I was right to put more time in.

Also, I don’t know if this is just me imagining things, but the game seems to lock up faster if you “idle” more. During this session, I spent the majority of my time rearranging my party, calculating fusions on another window and just leaving emulation paused while I was AFK, while in the sessions where I’m out dungeon-crawling, it could take over an hour. Could explain why I didn’t spot any issues with 1782 the first time around; I did a lot more dungeon-crawling then.

I recall idling in menus and leaving Citra paused for a good while when that happened. But I don’t know, maybe it’s just a big coincidence.

Not sure if it’ll help but this seems to be a recurring issue, I found a thread that seemed to have dealt with the same issue. the solution mentioned it seemed to be related to in the persons own words linux’s (extremely junky) hibernate/suspend system.

not sure if this’ll help but it might narrow down somethings

It seems to be related to the ‘New 3DS’ mode. I haven’t tested it extensively, but the game hasn’t softlocked since I turned it off.

I can’t say for 100% so far since I only played for like 30 minutes but I am doing all the things that caused the locks before

  • Keeping it on tabbed out citra for a while
  • Loading and doing same steps over and over again
  • Opening certain dialogues like talk in shop
    And so on… And so far? Looks like disabling the New 3DS mode did the trick
    If it actually works now that’s great, I wanted to play the game again after loosing my old 3DS some time ago and I was bummed that it was bugging out like that on Citra, but this actually seem to be working. You good sir, or whoever gave you the suggestion, deserve a medal

Some things I still wanna make sure will work but don’t have time for right now

  • Will try save state later which made it that if you follow exact steps on map it will always freeze in exact same spot
  • Will try adding DLC later as well since that also made it buggy
1 Like