I’m looking for a way to lock frame rates, like 30 fps for games that have unstable, unlocked frame rate up to 60.
Sure i can use something like RTSS, but that doesn’t care what core you are using, it will lock RetroArch as a whole, even the menu. So i’m looking for a way to lock frame rates per core or per game, just like any other option.
Maybe there’s a shader that can do this?
You can’t do that with emulators. If you lock a 60Hz core to 30FPS, the game will run in slow motion (at half speed.) In fact, that’s exactly what the slow motion feature of RA does. It caps FPS and you get slow motion as a side-effect of that FPS cap.
What you need instead is frame skipping. Some emulators have that option, so look for it in the core option of each core.
A frameskipping-like trick you can try: enable threaded video and then fire up a shader that’s too heavy for your GPU.
Some cores like Flycast, Kronos, have the option to skip frames, if the game runs at 60, it sets it to 30.
But frame skipping won’t produce an evenly distributed frame rate, will it? On a game that already has an unlocked, variable frame rate, frame skipping will halve the frames but they will still be variable, no?
Also, not all cores have frame skipping. I’m interested about the N64.
Ok, here’s what i’m trying to do: I play Goldeneye with the core options to overclock the N64, so Goldeneye runs at 60fps. It does run at that frame rate most of the time but it still has dips in various places, nothing i can do for that no matter the settings. So i want to lock the game at 30fps instead of 60 while keeping the same overclocking. This way the overclocking will easily allow the game to run at 30fps while the fps lock won’t allow it it to go higher.
Are there any suggestions on how to achieve that?
That didn’t work. The frame rate was reduced but it was still uneven with more slowdowns and on top of that the sound was also affected because the emulator couldn’t run at full speed.
Skip frames in 1, display one and remove one, 60/30. In two, display 1 and remove two 60/20. It creates jumps, but it is stable and is used when it exceeds the hardware. I don’t know if N64 has this option.
Yeah that’s true if a game runs at 30 or 60fps. However, Goldeneye does not run at either of these. It’s completely variable.
If i overclock the N64, i can get it to run at 60fps, which it where the game is capped. But it also drops at 30ish in places, there is no way to avoid that even if i use the highest overclocking (which is why Mupen sucks at this compared to PJ64). So, if i use 1 frameskip, i will get half of 60 (30) but also half of 30 (15) at those parts where it drops. So it wont work. That is if the core had a frameskip option, which it doesn’t.
What i want to do is make the game run at 30 at all times, stable. Overclocking will help the game reach that frame rate easily but it seems there is no way to cap it at that and not allow it to go higher.
It might be a dumb question (i never ran a n64 emulator), but is it because PJ64 allows higher overclocking or something ?
Maybe you could request on mupen’s github repo to increase that cap ?
PJ64 has an obvious multiplier for overclocking. For instance, you can make the system run 2x as fast, or 3x, 4x, etc. It’s pretty simple and self explanatory. At 3x, it can brute force Goldeneye at 60fps, even during the most demanding scenes, like when you exit the first tunnel in the first level.
Mupen64plus-next has a “count per OP divider” that goes from 1 up to 11 and i’m not sure how it works exactly. From my tests it doesn’t seem to have any differences after 4. Goldeneye does run at 60fps at 4+ but it will always slowdown at the more demanding scenes like the tunnel i described above. Even at 11, it can’t brute force the game to run at 60fps everywhere (and it’s not my host system, emulation speed is always 100%).
I already asked everywhere for any information about how this option works, but it’s still very vague. I asked in Github where i made the original overclocking request for the core, asked in discord, reddit and even here in this very forum: Has anyone figured out how "count per op divider (overclock)" works?
Either way it’s not very good or at least it doesn’t work as well as it does on PJ64.
I’ve never had any luck with overclocking, I can’t get anything to work.
There are options here that are in development, that is, they may fail or not work correctly.
“CountPerOp” is not on the official wiki, not even on the development wiki, but you can get some extra information in the development wiki sketch that is on github and has not yet been published.
The meaning is quite obvious. Count per Operations of the processor cycles. This is what any overclock does.
I understand that setting “Count Per Op Divider” to 11 would not be convenient, because it divides, and if “Count Per Op”, which is the overclock, is not active, it has no effect.
It seems to me that there is misinterpretation because the wiki sketch says:
Reduce number of cycles per update by power of two when set greater than 0 (overclock).
That is, if it is set to 0, the overclock is maintained.
These options are ideal for fine tuning, but if you want the highest speed, the ideal option is (or would be) “Framerate at Fullseed”, it will show the maximum that the host hardware can display.
Trying other options, “Frame Duplication” smooths the frames for me quite a bit, and “Threaded Renderer”, in the GLideN64 options, which should be ideal for these cases, does not work for me.
P.D.: An idea. It would be advisable to use the same name that the original emulator uses, to facilitate the search in internet, “Count Per Op” in the standalone is “CountPerOp” pasted.
I searched a lot about this over the years but i gave up. This simply doesn’t work as good as in PJ64, that’s the end conclusion. Tried everything, any combination i can think of. If i want to play Goldeneye at 60fps i use PJ64.
For overclocking to work you need to have counter per op to “1”. There is a similar option in PJ64 that also needs to be at “1” for the overclock multipliers to work. Counter per Op “1” will make games run smoother either way, even if you don’t touch any other option.
That’s why I told you, it’s a feature under development.
This is what I understand from their wiki. At 0 it is off, at 1 it is on, at 2 the frames are doubled, etc. The divider takes the max frames and divides them.
I don’t know if it is compatible with vulkan or it is not well implemented in RetroArch. No idea, if you can try the standalone, even, in their github, they may give answers on how it works, in the forum there are many comments on this.
It works just like the standalone.
“0” isn’t really off, just “undecided” really, if you set it to “0” it will act like “2” which is the default.
“1” is what you need if you want to increase the frame rate/performance in a game. It won’t do much for locked games but it will reduce slowdowns. It’s not overclocking though and won’t eliminate all slowdowns. But you need it in combination with an overclocking feature.
“2” is the default, supposedly “correct” speed but ofc this isn’t the case when these emulators don’t have accurate timings. Most games will still run a bit faster or slower but if the timings were accurate, this option would make all games run like real hardware.
“3” and above will make games run/react slower than normal. I don’t think i have ever found any game that works better with those, maybe if the emulation is bad and a game runs too fast.
The “ Counter per op ” is a pretty old feature, it was there since the beginning in both Mupen and the equivalent in PJ64. I was messing with it in 2005 to reduce slowdowns in Starfox 64. It’s not overclocking though, it’s more like messing with the timings to make the emulation react faster or slower or something like that.
The new feature is the “ counter per op divider ” (or the overclock multiplier in PJ64). That’s the one that didn’t exist before and it’s the supposed overclocking feature for this Mupen core as per the author. But apparently it works in a different way than in PJ64 (author also mentioned this) and doesn’t give the same good results as PJ64 (or Mupen 64 FZ, which has a similar multiplier as PJ64).
From what i have gathered, its not really overclocking, it’s just further messing with the previous Counter per OP timings. So if you choose counter per Op “1” and divider to “2” it makes it 0.5 or something close to that, making the timings even tighter and the game performs faster. But again, it’s not overclocking, games will still slowdown no matter how tight those timings are, even with the divider to “11”.
That’s the issue, since the author has added this as an overclocking equivalent, the core will not get a proper overclocking feature as the github suggestion/request is considered finished/closed.