-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
bsnes v112 released - Run-Ahead support added
- Thread starter SoH
- Start date
How ressource intensive is it? IIRC run-ahead is pretty costly cpu-wise and bsnes is one of the most demanding / accurate emulator right
You need to be careful with how you use it or you could lose frames btw
Byuu explains here:
Yeah, BSNES has been the gold standard for around 13 years. ZSNES effectively died around 06.
Very intensive, as it basically adds an entire instance of the emulator per frame, but byuu has added a new ppu which is super fast, so that mitigates it somewhat.
Byuu explains here:
Yeah, BSNES has been the gold standard for around 13 years. ZSNES effectively died around 06.
Very intensive, as it basically adds an entire instance of the emulator per frame, but byuu has added a new ppu which is super fast, so that mitigates it somewhat.
I'm not sure if the standalone has the Balance/Performance/Accuracy options like the Retroarch cores do, but if it does, the Balanced/Performance options should allow you to use run ahead without having tip top specs.
Alternatively, damn near every core in Retroarch except for the disc based (PS1, Saturn, etc) cores can utilize it, bsnes Performance and Balanced as well. Or you can just use SNES9x.
Depending on the game you're running, bsnes will end up distorting the audio even if the game runs solidly because of how resource intensive things are. If you're unsure about your specs and performance, I recommend just using Retroarch cores. I've bumped up run ahead by six frames on 9x and some Genesis emulators. The biggest issue for me was the rubberbanding of sprites and backgrounds once movement stopped.
Yeah, there's somehow still an official ZSNES forum and it looks like the developers are MIA. Presumably they've gone off to software companies and have to pretend like they never had anything to do with the emulator and therefore have completely vanished from the scene.
I will have to check this emulator out. I've used it before but not too in depth.
Byuu puts BSNES on his resume I think lol
BSNES now has the fast PPU on by default, it only changes to the old accuracy profile for the one game that needs it (Air Strike Patrol)
So if I understand correctly from the video, once an input is pressed everything seen is "rollforwarded" (as in inverse of rollback) x frame from the future, x being how many frames run ahead you set. If that is the case, then this technique wouldn't really help your reactions against obstacles, bullets etc right? If a game is 3 frame input delay and your muscle memory takes into account that 3 frame to dodge a bullet from y distance, you would still need to press that jump button at that y distance because the bullet will teleport forward toward you for 3 frames worth of travel time as soon as you press the jump button.
bsnes is the gold standard but is very resource-intensive. Snes9x is the second best SNES emulator and is for all intents and purposes the better emulator to use because its accuracy is pretty much indistinguishable from bsnes for 99% games, and it is less resource-intensive.
Maybe 5-10 years ago, but these days most computers would get 60fps or more on bsnes, so that's not true.
Hmm... well, this is all well and good if you're just sitting still and testing input lag, but if you're actually playing the game, moving around and fighting enemies, wouldn't the skipped frames make things a bit weird?
I have an i7-7700 3.6GHz and sometimes, like every 30 minutes or so, I have some annoying cuts with "audio sync" on, so for some long hours of play I still prefer Snes9x in some cases, depending on the games.
Of course BSNES is by far the best SNES emulator ever. ZSNES was dead even before 06, I would say in 2002 it was heavily surpassed by Snes9x but people with low spec PCs keep it for years, thinking it was the only option even to this day. There are some people that still uses NeoRageX so...
Sweet, even better.
Given everything is accessible with a controller, I still champion the libretro method even though I hate the interface, but going straight through bsnes is perfect for people who tend to use standalone emulators.
Oh people still use ZSNES even with good PC's, sadly, the whole "it works for me" is strong in many folks. well if they are comfortable with it i suppose.
I remember ZSNES having a shit ton of issues with MMX3. Is that still the case? I know I stuck with Z for the longest and only switched to 9x because of that.
Well, let's say that "it works for me" people only plays mainstream games, that's why and I could kinda understand that... but for me it's a no no, especially after people found this.
ZSNES last update was in 2007. The "1.5" is an unofficial git version from EmuCR.
It probably does, it hasn't been updated in years, but it's so famous that people stick to it.
People should really switch. It's like continuing to use Ask Jeeves.
Higan's SNES core is still the most accurate emulation available. This new version BSNES has been built from the ground up to be far less CPU intensive, comparable in accuracy with it's new fast PPU mode to SNES9X, deliberately targeting lower spec hardware and to allow features such as hd mode 7 and run ahead to be used so Higan can be developed purely with accuracy in mind.
There is no frame skipping as you would imagine it or teleporting of that type, run ahead doesn't suddenly active when an input is given. If run head is set up correctly then the experience is as smooth and consistent as if you didn't have it enabled at all.
There is no frame skipping as you would imagine it or teleporting of that type, run ahead doesn't suddenly active when an input is given. If run head is set up correctly then the experience is as smooth and consistent as if you didn't have it enabled at all.
How can you say there's no frame skipping, it's literally how it work in this video, it skips to the frame +3 that was ran ahead when megaman jumps or shots https://www.resetera.com/threads/bsnes-v112-released-run-ahead-support-added.148064/#post-25605868. He even shows how when you put a too high run ahead you skip the whole start animation and reach the state where megaman has shot in the past, the bullet already ahead.
OP
OP
That's the idea. You want to keep it under any animation frames so the skipping is imperceptible. You are skipping the frames where nothing is happening. Byuu says it is smooth even in cases of scrolling but I haven't had a chance to experiment.
That is why this is all case by case from game to game but generally 1-2 frames is enough.
Edit: skipping may not the best term here.. it is more like you are always seeing X frames in the future but making that too aggressive will make it feel abrupt from one actual frame to the next since the further out that is being rendered the larger the change will be over time.
I understand this is not extremely easy to wrap your head around so I've been trying and falling to think of some intuitive examples. We need a Schrodinger's cat of run ahead.
Last edited:
no, i said that the game is not skipping frames as you would imagine. the way the guy who integrated the method into retroarch described how it actually affects what you see and how the game responds is like this. a setting of 1 frame of run ahead is like tuning on your snes and instead of seeing the 1st frame you instantly see the 2nd frame in its place instead. then you see the 3rd frame where the 2nd would have been if run ahead was off. this then repeats for every single frame so nothing is missed but the very first frame, nothing else.
which is a perfectly good example of how to not set it up, only remove the amount of frames of latency that a particular game has and no more.
i believe that true 60fps will only be possible if someone rewrites the games engine .
it doesn't matter if anything is happening or if you are pressing any buttons, run ahead is always working so nothing but the initial frame(s) is skipped, that's why everything can be perfectly smooth and act as if it were not enabled at all. i think im clearly failing to put across exactly how anything is being skipped but it isn't like the game is running normally then suddenly skips just because you have pressed a buton.
OP
OP
Yeah I went back and listened again and realized that doesn't really explain it well.
It is funny because it is really not that complicated but it is also not easy to put into a single sentence.
I watched this and I still feel like I don't understand how runahead works. It saves the state when you press a button, then runs a gram that isn't seen, and then loads the state, right? But I don't understand why the loaded state would look any different to the user than if nothing happened at all. And if we aren't seeing the frames between when B is pressed and Mega Man fires, wouldn't there be visible judder in enemy and background motion?
Oh that actually makes more sense. I was thinking of the process as starting with an input rather than for the whole time. So when you enable runahead mid-session, you will miss a frame. Got it now thanks
That's cool but I'm already using SNES9x with retroarch and hard GPU sync enabled which brings down the latency a lot.
I would only recommend this for hardcore SNES purists.
Also stop using ZSNES period. It's garbage.
I would only recommend this for hardcore SNES purists.
Also stop using ZSNES period. It's garbage.
You'll be glad to know bsnes has the snowflakes now.
OP
OP
We need a purple background before the Nesticle Cursor & Icon Pack
So for the people with only tangible understanding, is there any reason to use this instead of Retroarch with Run-Ahead?
The bsnes libretro core is now upstreamed, so it's up to date with stand alone. It's honestly pretty fast; hard sync enabled with hard sync frames 0 is no problem on my 2500k. I would say it's now the most balanced option as far as speed, accuracy and features is considered on PC. It does have a flickering issue while the RetroArch menu is active, but it's well known with the devs, so I imagine it'll be fixed soon enough.
Mesen-S is also a really good accuracy option from my testing, but it's quite a bit slower.
Yep. It's just called bsnes on the updater. The older cores had 2014 suffixed to them.
I went ahead and made a video myself using Mega Man X as an example; I ticked run ahead forward six frames, and you can see what kind of craziness starts to happen.
This actually starts once you get to three frames ahead and only gets progressively worse. And this is just Mega Man X; some games get this bad at two frames.
This actually starts once you get to three frames ahead and only gets progressively worse. And this is just Mega Man X; some games get this bad at two frames.
Functionally the same thing, but if you're a person who prefers to use standalones for whatever reason --faster updates, newer features, etc--you get all of the options.
Well, you can't really upscale sprites. Not sure if bsnes standalone has any filters, but a variety of filters are available for it and emulators in general through Retroarch. There is a mode in bsnes to make certain aspects of games (overworld in Secret of Mana, stages in Mario Kart) HD with anti-aliasing and whatnot so they're less jittery and ugly, but not upscaling in the traditional sense like you would get out of a PS1 or Dreamcast game.
Even though I think I have an understanding of how it works, it's actually more complex to explain than I thought.
I don't know if this graphic I put together will help, and it's possible that changing the labeling might explain it better.
In Super Mario World, it takes three frames for Mario to respond to a jump input.
That's nothing to do with emulator lag or your display; it's built into the game.
With 2 frames of run-ahead emulation, the game is rendered at 3x speed, and you only ever see the third frame.
Via the magic of save-states, any inputs you make are captured and sent back in time two frames prior to when you actually made them.
The jump animation still takes three frames, but because your inputs happened two frames ago, the jump animation occurs on the next frame that you see after pressing the button.
Animations remain as smooth as they always did, because the game is still rendering a steady 60 FPS stream of frames - you just stepped ahead two frames in the timeline. What you see is always two frames ahead; it doesn't jump two frames when it receives an input.
OP
OP
It really is funny. You are like, what is the big deal I'll sit down and write some words. And then 4 paragraphs later you realize your blathering is not as clear as you assumed it'd be when you started. I think you did an admirable job breaking it down.
The only thing I'll add..
This is true, and important not to overlook, though by reducing the engine lag effectively to 0 (or as close to it as you can) you are compensating for those problems like display lag or USB polling to make the game feel more responsive while changing nothing in your setup. Remove those other problems as well and you end up at better than original hardware for input lag, as you see the claims going around.
I don't think a thread needs to be made for every emulator release, but this is one of those features that as time moves forward should be expected and better awareness is important. Nintendo can get away with not having it in the Switch NES/SNES games today because it is relatively new and fresh. A few years from now? Unless something better is found releasing a commercial emulated game without this feature should be boo-worthy.
