I’m not sure what you mean by that ? Afaik no core with hardware acceleration has implemented what i was talking about, and flycast isn’t an exception.
I’m the one who doesn’t understand.
What do you mean by this, I have been using Run-Ahead with Flycast for a long time. With volcan or glcore.
And the article is new, from the current version, what do you mean by this?
“so cores that currently rely on OpenGL/Direct3D11/Vulkan are a no-go.”
I did read the technical explanation you gave us, but it was the same or worse. 
The value at https://github.com/libretro/libretro-super/blob/master/dist/info/flycast_libretro.info#L20 is disabling runahead, netplay, rewind and preemptive frames for that core.
Did you manually edit that file to change that value on your setup ? Are you using a several years old version of retroarch where this value didn’t matter yet ? Because otherwise runahead will be automatically disabled at runtime with flycast.
Let’s make another attempt at explaining the hardware-acceleration thingy :
- software-rendering : at each frame request by retroarch, the core is rendering a flat image on a framebuffer, it’s not communicating with the gpu, retroarch is the recipient for that framebuffer and will decide to send it to your gpu for display or not.
- hardware-rendering : at each frame request, the core is directly using the gpu to render on screen using the gfx api it is compatible with (d3d, gl, vulkan), it’s entirely bypassing retroarch so retroarch can’t control whether the frame will be displayed or not.
Since the concept of runahead is about making additional frame requests, it is important for those additional frame requests to not be displayed on screen.
1 Like
years no. In October/November of last year was the last time I used Run-Ahead with Flycast, it was not smooth, but it worked. Now I see that it is disabled, and you can’t even see the option.
I know what software and hardware rendering is, what I don’t understand is what you mean by this.
We are talking about the need for clearer explanations for the common user, and this is not exactly a friendly explanation.
Let’s see, it is not necessary to complicate things, you are saying exactly the same thing that I said.
Run-Ahead is not supported on emulators that use hardware acceleration.
The driver that is selected in the retroarch interface is not the same as the one used by the Core, because the core automatically selects which one to use.
Libretro is an api used for communication between a backend (the core) and a frontend (retroarch). There is an apicall telling if the frame should be displayed on screen or not. Implementing that apicall allows a core to know if it should skip anything related to displaying. I can’t give a better/easier explanation.
1 Like
The hardware-rendering APIs don’t like hopping around in state multiple times per frame, which makes them not play nicely with runahead. However, the callback that barbu posted lets the frontend tell the core “hey, this frame will never be seen/heard, so don’t bother actually rendering it”. If properly implemented, this would allow a hardware-rendered core to only actually render the final output frame instead of needing to hop around and render all of the intermediate frames.
This is essentially what Swanstation’s internal/core-option runahead does, so it would be a good first target, I think.
Likewise, bsnes’ core-option runahead exists because bsnes has 2 different kinds of savestates: one that is non-volatile but also non-deterministic, and one that is volatile (that is, not usable from session to session) but deterministic (i.e., the same outputs from the same inputs every time). At the time the core was implemented, RetroArch only supported hooking up a single type of savestate, so it was a matter of either breaking bsnes’ savestates as an actual saving mechanism or breaking the frontend’s runahead via non-deterministic savestates. Now, we can have our cake and eat it, too, by letting the core communicate to the frontend what kind of states it’s using for which activities, but again, nobody has actually hooked that new capability up to the core yet.
5 Likes
This is a friendly explanation. LOL
Although, I don’t really know why we got this far in the conversation. The point is, what are the differences. Run-Ahead is slower and doesn’t support hardware acceleration. But it used to support it, Cyber mentioned it to me and I had used it too.
In the release article it is not reflected, maybe it is not necessary an explanation as advanced as BarbuDreadMon’s, or as detailed as the one you give us. Something more simplified like “due to development complications we have decided to disable hardware acceleration support in Run-Ahead, in favor of Preemptive Frames”, to inform the common user that he will no longer have a feature he used before. Just a thought, I think it can be useful.
You are misunderstanding this, runahead does supports hardware acceleration, it’s just that many cores (both accelerated and non-accelerated) still require work to support runahead. That sentence in that blog post is just an oversimplification of the fact that (afaik) none of the hardware-accelerated cores does support runahead at the moment, for the fair reason that it does require more work than the average software-rendered core.
Are you still talking about Flycast here ? I gave it a try after changing the value in info file (you just need to set it to “deterministic”), it was total crap :
- not running full speed even on an i7-12700k
- randomly crashed with an “illegal instruction” error
- i’m also pretty sure i noticed gfx issues
Flycast doesn’t support runahead properly, hence why it was disabled, it has nothing to do with preemptive frames or development complications.
1 Like
Are you understanding what is being talked about in the post?
I don’t even know which post you are talking about. All i understand is that you are wrong about flycast ever supporting runahead, it’s way too crappy to be called “supported”, and it has nothing to do with preemptive frames or development complications, it’s simply that nobody cared optimizing it for runahead.
Dynamic recompilers also can have issues with runahead, for the record. Many cores that use hardware acceleration also have dynamic recompilers, so it’s not always easy to tell which is the problem (I believe the random crashing barbu described is due to the dynarec not liking it).
Supposedly, preemptive frames can play nicer with hardware-rendered cores but in my experience that has not been the case and I haven’t seen any mechanism in the code for that to be the case.
1 Like
This very post you write, read it from the beginning.
Summary, this article in the current version 1.15.0, says it is not compatible with OpenGL/Direct3D11/Vulkan.
I was using Run-Ahead Flycast with Vulkan and glcore.
Imperfect and flawed but it worked, and for what I was doing it served me well.
Until November of last year I was creating a high resolution texture package for Soulcalibur, Daytona, Virtua Tennis and What’s Shenmue. Run-Ahead in Flycast with Vulkan or glcore, widescreen and texturepack enabled.
Yes, I could load a state, but I liked backtracking better.
Playing, I don’t know. I never play games.
And on older machines, Preemptive frames works like jumping around.
Is there a way to create a table and have everyone test it and post the results? Something like a testing period before officially launching it.
1 Like
I already explained it’s an oversimplification, and that various tools (apicalls) to fix well-known problems with runahead have been available for quite some time, some written by myself. It’s up to the core authors to decide if they are interested in implementing them. I personally use all of them in FBNeo, hence why even boards like cv1k became playable with runahead, while they originally weren’t.
It crashes, glitches and needs a quantum computer to run at full speed. The purpose of runahead is to improve gameplay, not the opposite, saying it works is just a very unreasonable overstatement, so it seems only fair that someone disabled it. Yet if you miss it, i already told you how to reenable it.
2 Likes
Yes, I recently discovered PRs. Cloning the repo, making modifications, etc., etc. A common mistake in open source software projects is to believe that everyone knows about it, or that it is the only thing that is needed. They almost completely ignore the relationship with the user. But this is another matter.
I have not used them for two reasons.
The first is ignorance, I don’t know how to use it.
The second is that these are very obvious things and I’m not going to bother about something you already know (?).
Testing a new feature is a no-brainer, and making test sections with the community is something that has to be done by the administrators involved.
Also, that this is a great opportunity for promotion and to consolidate the community around RetroArch. “BETA”… “A new feature, we need testers”, spreads like wildfire. There are projects (such as Ubuntu) that have understood this very well.
But, I’m going to try to open a PR, maybe I’ll get lucky.
Don’t worry about it anymore, there is no doubt.
If preemptive frames works well, I won’t miss it, LOL…
Anyway thanks for the tip, I’ll play the code to see if I learn something.
I’ve been meaning to ask you and I forgot. If I’m that determined guy, and I want to make all the Atari 2600 games, what do I have to do? a written list? save the settings per game? I don’t know.
I’ve noticed that some games/cores give me graphical glitches with pre-emptive frames and with single-instance runahead, but not with two instances of runahead.
For example, this is Mizzurna Falls on Beetle PSX with no latency options, and with two instances of runahead:
This is the same scene with pre-emptive frames, and also with one instance of runahead:
Notice the red object behind Matthew’s portrait. It flickers. This is a static scene where I’m not pressing any buttons.
Not sure what causes that. The menu description says that some games need a second instance in order to avoid audio problems, but I didn’t know that you could also get graphical problems.
1 Like
Yes, as i was mentioning some cores require second-instance because they won’t work properly with single-instance (and preemptive frames by extension).
2 Likes
I think a collection of per-core/game overrides that someone could plop right into their “config” directory would be the best idea. That’s pretty much all Shmuparch is.
1 Like
Per core, per game? 
If I think of making the Snes ones, I’ll last 300 years.
And now, I don’t know how to save the configuration per game, it doesn’t have a save option and Manage Core Options, it doesn’t save the latency.
Wouldn’t it be better, to have a list only with the game names and latency, and have it load automatically, if an “automatically activate” option is enabled?
It is that the games are repeated a lot, in console the regions is not so painful, but in arcade, the games can have 17 clones, and all the same.
You don’t have to make them all via the menus. The override will just have a single line with the number of runahead frames, so it’s only slightly more difficult than adding them to a spreadsheet to instead create a text file named Gamename.opt that has just:
run_ahead_frames = "X"
In fact, since it’s very rare to have more than 3 frames (and the vast majority will be 1 or 2), you could just have a couple of files (one for 1 frame, one for 2 frames, etc.) that you copy and rename over and over.
3 Likes
ahhhh!! I understand, but something I’m doing wrong or it doesn’t work.
In the file “Sonic The Hedgehog (Japan, Europe, Korea).opt” I put the line run_ahead_frames = "6" and I also tried with the line genesis_plus_gx_run_ahead_frames = "6" and it does nothing, it takes the Run-Ahead or Preemptive frames previously configured.
I think that option is not activated per game, but in general. If I activate 5 frames in Flycast, when I open any other game it takes the 5 frames.
Yes, most will run at those frames, but I have no problem testing each one to get it right. The problem is that each core has different latencies, with each game…
I took Nes, which should be simple to try and have had a few surprises. Tested on all 4 cores, all work the same.
Adventure Island Jump 1, Axe 1, Walking 2, 3 o 4, this is another random case, the funny thing is that it always flips on the second frame, then it may take a while to start.
In Castlevania 1 each action has a different latency.
Jump 3, Whip 2, Walk 1, Crouch 2.
And currently, Preemptive frames works very well, it has the same performance as Run-Ahead, before it gave me lags.