I'm working on a patch (which can be a pull request later if you want) that adds a second frame skip setting. The patch is 99% done but the fps variable doesn't seem to be right when I try and use it. Let me explain...
The auto frame skip feature doesn't do what I'm trying to do. I have a need to set frameskip to 1 for games that run at 30fps and set it to 2 for games that run 60fps.
I've successfully added the menu options and updated the doframetiming function to use the new setting, but in order to identify if the game is 30fps or 60fps I'm checking the value of the fps variable and for some reason in the doframetiming function it's value isn't 30 or 60. I've converted it to an int first just to make sure there's no decimals. Any suggestions?
Additional detail - when I enable showing fps on the screen I can confirm the fps for the game shows as 30 or 60. The code that displays this on the screen calls __DisplayGetFPS which then simply returns the value of the fps variable. So it's the right value at that point?
Depends how you're converting to int - if you're rounding down it will most likely be 59 and 29, since it's NTSC.
If you want to strictly flip that way, it'd be more accurate to use numVBlanksSinceFlip. That will steadily increase every vblank (which occurs 60 times every 1.001 seconds, or 59.97 times per second, NTSC timing), and is reset to 0 every time we see a drawn frame.
In practice, that means numVBlanksSinceFlip will be 0 for a 60 FPS game, and 1 for a 30 FPS game within DoFrameTiming. That's why we send numVBlanksSinceFlip * timePerVblank. Anyway, the benefit here is that numVBlanksSinceFlip is an integer so it's relatively "safe" and you don't have to worry about rounding errors.
Be aware that sometimes it may be greater than that, e.g. 4. This happens because games will sometimes go several vblanks without drawing things during loading or etc. At that point, there's no way to tell if it's 30 FPS or 60 FPS usually (and it may be transitioning between a 60 FPS gameplay area to a 30 FPS gameplay area.)
-[Unknown]
I'm simply assigning an int variable the value of fps and letting c++ handle the conversion. So perhaps it would be ideal to say if fps < 50 then assume its 30 otherwise use the 60 fps setting. That way I don't need to worry about other possible values of blanks since flip. Unless you think that's a bad idea, I'll give that a try and report back.
I "think" the doframetiming function would get called beteeen those scene transitions and automatically use the 30fps vs 60fps setting depending on the value of fps at the moment.
Well that didn't work haha going to try with blanks since flips
That didn't work either :(
When checking fps it always uses the new setting I created for 60fps, so fps must be evaluating above 50 even for 30fps games.
if (fps < 50) { frameSkipNum = g_Config.iFrameSkip; } else { frameSkipNum = g_Config.iFrameSkip2; }
When checking numVBlanksSinceFlip it's always using the original 30fps setting, meaning it's always evaluating to zero (or less).
if (numVBlanksSinceFlip > 0) { frameSkipNum = g_Config.iFrameSkip; } else { frameSkipNum = g_Config.iFrameSkip2; }
I'm going to add CalculateFPS() just before I evaluate fps and see what happens. Am I missing something?
So I have just verified that even when the FPS in the corner shows 30 for the game, the variable fps is equating to around 59-60. Upon further inspection, __DisplayGetFPS is passing the variable "flips", not fps, to be used in DrawFPS. Edited my if statement and I expect that to work this time around :)
Yep, worked like a charm. Would you like me to submit a PR now that this in place and working well on my build?
can you provide your patch work? I want to try
I wasn't going to bother finishing applying the patch to other platforms until I knew there was interest, seems like there is, I'll finish it up (3 or 4 more instances of iFrameSkip to update) and submit a PR for others to test.
can i try it later if you have finished everything?
Yes, the pull request will be able to be used as a commit to pull, or a patch to download
thanks. I will wait for him. Keep the spirit.
Here you go: https://github.com/hrydgard/ppsspp/pull/11505
@owengque - in case you didn't know, to generate a patch from this PR just add ".diff" to the end of the url.
Important note - the changes for the linux build work well, so the windows, qt, and libretro environments are untested.
i only have android :(
can add on apk?