scePowerSetClockFrequency seems to cause timing issues when set repeatedly #2104
Comments
|
How frequently does it call it? Does it call it with any numbers between 222/333? -[Unknown] |
|
I'm not exactly understanding how the timestamps work in PPSSPP's logging, but here's what it's done up to the point that it begins to 'slow down': Another thing to note: The VPS isn't affected by this.
|
|
The timestamps are MM:SS:sss of the current local time. I've been thinking having the same into gameplay per gameclock would be much more useful... If a game plays around with the clock rate a lot, events may happen at the wrong times. For example, vblank, vtimers, alarms, all wait timeouts, etc. That's because it's translated to ticks and time of set, and not adjusted. Could try rescaling all events by the new/old hz ratio on change, hmm. But really, just a few changes like that shouldn't cause an issue, I'd have thought... -[Unknown] |
|
Do you think a debug log would possibly shed any more light on this? |
|
Hmm, not sure. Maybe. Also, I have some minor changes to these funcs sitting around, maybe it's calling others. This doesn't help, does it? https://github.com/unknownbrackets/ppsspp/compare/power -[Unknown] |
|
could that be what is going on with BBS in #2066 ? |
|
@unknownbrackets : Adding the new code from your power branch didn't really help. The animations in Diva 2nd still get choppy after about the same amount of time as before. Thanks for having a look at it, though. I appreciate it. |
|
Another interesting tidbit: If you go to the main menu after it begins to 'lag', and then try to go to any option on the main menu, it hangs forever. Edit: What the? It loaded after about 15 seconds..that was odd. But it's still interesting. Also, after it loads, the 'lag' seems to go away. |
|
Maybe should check if it happens on the real PSP too :) |
|
@hrydgard : It doesn't seem to happen on the real PSP. I let Diva 2nd run for a good 25 minutes on its own and the animations were perfectly fluid. |
|
Sounds like this is actually just #2010 in disguise, since it temporarily sets to 333 and we have some very delicious fudge factors for that mhz. -[Unknown] |
|
Do the timing changes in #4286 improve this? Or the changes to gpu timing delicious fudge? -[Unknown] |
|
It seems to be fixed now, yes. But I'm going to do some more in depth testing(e.g. go back a few revisions and see if it was indeed fixed by either). |
|
Yeah, I'm pretty sure your stuff fixed it. As for which commit did, I dunno yet. I'll bisect it later out of curiosity, but at 0.9.1-2123-g6c5a2ea, the bug still existed, and the next available buildbot build(v0.9.1-2145-gbadf33a) did the trick. |
|
I expected 9c874c7 to fix it, so it's probably that one. scePowerSetClockFrequency() used to act as a DeLorean, but it doesn't anymore. So I'm going to close this issue. -[Unknown] |
|
@unknownbrackets: Yeah, that was the one. I tested the commit just before it and the bug still existed, so indeed, that one is the answer. |
Some games like Project Diva 2nd tend to ramp up or slow down the CPU, bus, and PLL speeds as needed(switching between 222/222/111 and 333/333/166), but it seems to cause timing drifts over time. If you let the intro/attract sequences of Diva 2nd run for about 10-20 minutes, the animations of the 3d characters begins to get sluggish, and when it cuts out to demo a song, the scene never seems to finish animating the 'intro' sequence, simply playing the music in the background.
Now here's the interesting thing: if we hardcode the CPU/PLL/Bus speed to 333(or perhaps 222, I didn't test with that), the timing issues magically vanish.
The text was updated successfully, but these errors were encountered: