yep, it’s jumping to zero.
With this new runahead feature, is the “Frame delay” option becoming obsolete ?
No, this is entirely different as far as I understood.
All the latency-related options that are currently featured in RA improve the input lag that occurs between the button press and the corresponding on-video reaction, which derives from a lot of varying factors (including V-Sync and this is where Frame Delay comes into play mainly). The emulation of the inherent lag of a game is left completely untouched and accurately preserved.
Run-ahead does something “bolder” in a way: it eliminates a user-defined amount of frames of internal lag, allowing you to get next-frame response by manually tweaking the values according to the individual title you’re playing. I believe these two concepts of input lag reduction are meant to co-exist and serve entirely different purposes.
2 Likes
I ended up removing the Hard Audio Disable feature entirely from the Genesis Plus GX core, until I can get it working properly.
Does this come at a performance cost but it’s generally safer?
Hard Audio Disable only applied for the secondary core. While it did speed it up, I don’t think it was worth it if there were crashes and stuff happening.
If we need a quick fix to re-enable the feature, I’d come up with a way to disable using the Nuke sound core in the secondary core.
That said, Genesis Plus GX works fine without using a secondary core.
Horribly Unrealistic Torture Test Comparison: (Run ahead 6 frames not using secondary core)
- Emulator built always forcing hard audio disabled: 420FPS
- Emulator not doing hard audio disable: 245FPS
More realistic comparison: (Run ahead 1 frame using secondary core, not touching any controls)
- Emulator built forcing hard disable always: 580FPS
- Emulator only using hard disable for secondary core: 570FPS
- Emulator never using hard disable: 560FPS
I would like to ask a question about the second instance option.
I understand it’s there for the cores that have issues with audio when using the run ahead feature. But does it cause any problems to the other cores? I mean, can i have it enabled all the time when i use the feature and forget about it?
Question about this new feature. Is their any plans for Retroarch to automatically set the Number of Frames to Run ahead? Or will we have to just figure it out for each game and emulator? If so will this setting be tracked somewhere to have this zero input lag for every game and emulator? Let me know if I am misunderstanding the feature completely lol.
There’s no way for RetroArch to figure it out and automatically set it.
Retroarch does have code for identifying games. and does ship with a ROM Database.
It’s just that nobody has compiled a database of runahead values for every game.
Once you have a database with runahead values for every game, you can implement automatic selection of runahead values.
This is where crowdsourcing magic comes into play.
1 Like
The feature is so new that there are no known problems from leaving Secondary Core on all the time.
The only side effects I know of is:
- Always creates a new copy of the core’s DLL file in your temp folder and deletes it every time you run a game. (There’s no sane way to tell Windows to load a second instance of a DLL file without actually copying it elsewhere)
- Uses more RAM due to running a second copy of the emulator. So not only is the game loaded into memory twice, but also the emulator core, the emulated system’s memory, etc.
- When switching from the Main instance to the Secondary instance, the emulator code and data could have been pushed out of cache, depending on the processor’s cache memory. This could add latency.
- Not using the secondary core gives more consistent performance numbers, because it is not tied to how rapidly you are pressing the buttons.
- Audio is sampled from the executed frame rather than the shown frame, so there is small additional audio latency.
- Feature is not available on operating systems without library files. (like the Wii)
1 Like
Is it generally accepted that NES games have one built-in frame of latency, while SNES games have two, or is it not that simple (differences in programming methods back in the day, etc)?
No, not that simple. For example, Mario World is two frames and Donkey Kong Country is one frame.
Then Kirby’s Adventure on the NES has two frames of input lag.
It just varies from game to game. It is more common to find two frames of latency on the SNES though.
2 Likes
Thanks for the information regarding setting each game or not. Hopefully we can keep a running Google Doc or something once the feature is out in the wild. Its very promising feature and I look forward to it and I am sure the longer its out their the more information that will be gathered.
Let’s start compiling lists of every game on the NES/SNES/Genesis/etc. and the amount of built-in lag frames they have.
I am willing to add new metadata to libretro-database for the purpose of adding lag frame information to game entries.
6 Likes
What is the suggested way to test this? I have seen people use high speed cameras but it that the only way?
Just a word of advice for people measuring the frame lag of the games. Some games do not run at 60FPS, such as Joe & Mac on the SNES, which runs at 30FPS. If you try counting the lag frames for that game, you will see it vary between 2 and 3 frames of lag, depending on whether you started on an even or odd frame. Please record the smaller value.
1 Like
I think the frame advance feature is a good tool to test this since it’s about actual frames of lag being shaved off.
So, what are the cores so far that work nicely with this feature?
And what are the cores that do work but need a second instance?
I’ve gotten a few hours of playtime on SNES9X and Genesis GX and they seem to work just fine. I’ve only used 1 frame so far because my setup has about 1 frame of lag. I just want to be at parity with the consoles.
The only time it was necessary to enable the 2nd instance for me so far was when playing Final Fight on Sega CD. The audio would be choppy until I enabled that but I haven’t seen a drawback by leaving it enabled.
I’m using Sunday’s nightly build so I will need to redownload the latest next time I play.