Closed hrydgard closed 1 year ago
The purpose of skipping by percentage is to adjust the number of frames to be skipped based on current FPS, right? since we have auto-frame skipping that do that, is there a need for similar feature?
Well, auto-frameskipping doesn't specify a specific percentage of frames to skip, so it's not exactly the same. That said, auto-frameskipping is likely more useful than this setting.
The purpose of this feature was to dynamically calculate the frames to be skipped based on current FPS.
As we all know, games change FPS during gameplay and a hard-set number of frames to be skipped was causing issues when the FPS doubled in a game.
I have 3% as the default on my distros for any of the underpowered ARM boards. So yes it’s still being used.
Removing that setting feels like it will reduce backwards compatibility. But I can absolutely get on board with removing the set number of FPS and only leaving the percent as the option. I’ve never found the hard set number to be useful.
I have to admit I still don't quite understand the reasoning.
Yes, it makes sense to skip a fixed percentage of the framerate, dynamically. But these low numbers from 0-8?
And 3%? If as described, that's skipping about 1 frame out of 30 per second which seems it'd just lead to very uneven gameplay if it works like that.
Testing it though, that's not actually what happens. Setting it to 3 results in a 20fps framerate when I run Flower (which runs at 60fps) for example.
I think I need to understand better how it works and reword it possibly, but it can stay.
Let's see:
frameSkipNum = (int)ceil(flips * (static_cast<double>(g_Config.iFrameSkip) / 100.00));
So flips is the current estimated framerate. Basing the number of skips on that makes sense, but the formula doesn't quite make sense (although it does a reasonable thing), definitely doesn't match the wording though.
Basically all the formula does is to make it correspond worse to the other mode. I think it would make more sense to make a checkbox "Relative" or something, and divide by 60 instead of 100. That way, at 60 fps the two modes would match each other.
Though will need to think about what makes sense here. Either way, I'm not removing the setting, but I still think it needs change.
Oh, and thanks for chiming in!
Btw, just being curious, regarding the number of frames being skipped (ie. frameSkipNum). When skipping 5 frames out of 60, are they being skipped continuously (ie. 5 skips + 55 drawn) which can resulting to stutter/slideshow effect, or are they evenly spread (ie. 1 skip every 11 frames drawn) to get a smoother frame skipping?
The way the setting naively reads, one might assume it means "% of frames during a second to skip." In other words, 5% of 60 FPS would mean to skip a total of 3 frames throughout that second (presumably not all in a row, no.) However, this is not what it does.
Instead, the setting actually sets the number of frames to skip based on a percentage of detected game FPS.
Frameskip % value | Game FPS | Behavior |
---|---|---|
1% | 60 | Skip 1 frame (60 -> 30 FPS) |
1% | 30 | Skip 1 frame (30 -> 15 FPS) |
3% | 60 | Skip 2 frames (60 -> 20 FPS) |
3% | 30 | Skip 1 frame (30 -> 15 FPS) |
9% | 60 | Skip 6 frames (60 -> ~8.5 FPS) |
9% | 30 | Skip 3 frames (30 -> ~7.5 FPS) |
So, it is evenly spread. But the meaning of the percentage is just how to calculate the number of frames to skip evenly.
Personally I think this setting is somewhat confusing and maybe a "Target FPS" would be easier to understand as a setting (but it is somewhat nice that this keeps it even, i.e not using 20 FPS for a 30 FPS game.)
-[Unknown]
It was added in #11523 , but it's still very limited (can only skip up to 9%) and it's quite unintuitive to understand what it even does.
@mrfixit2001 are you still using it, for example?
As devices get faster, the need for detailed control over frameskipping gets smaller and smaller anyway, and this is a very obscure option at a very prominent location in the UI, so I'm considering just removing it.
(Yes, I know we already have some large issues about deleting settings, but I want to tag this one specifically with 1.15).