Having played Monkey Ball on a real Gamecube; on a CRT – I feel confident in saying the input lag is atrocious on Dolphin, is it just me?
 CRIME Shirt $21.68 |
 Nothing Ever Happens Shirt $21.68 |
CRIME Shirt $21.68 |
Dolphin Input Lag
Having played Monkey Ball on a real Gamecube; on a CRT – I feel confident in saying the input lag is atrocious on Dolphin, is it just me?
CRIME Shirt $21.68 |
Nothing Ever Happens Shirt $21.68 |
CRIME Shirt $21.68 |
Your monitor probably contributes a tiny little bit, but from what my understanding is emulators will always have input lag
TVs maybe but computer monitors have negligible input lag (or else using a mouse would be intolerable since it's probably the control method that makes us the most sensitive to input lag)
If your emulator supports runahead it can even be considered cheating because in most cases you will actually have less input lag than with the original hardware (a good example is Battle Garegga, which has 5 frames of input lag on the real arcade PCB so the advantage of runahead here is massive)
Runahead is shit. Its not an adequate solution.
But here's the thing, emulators add 1-2 frames of lag. So 16-33ms of lag. In other words, if you think you can feel it you're either superhuman or experiencing the effects of a placebo.
>Runahead is shit
Care to explain why? Every time I've configured it properly it just made games more responsive
It's because it is literally running the game ahead of where you are. So you get odd bugs. Let's say for example you are playing a game with 8 frames of lag and you're going really fast. If you make a sudden change in movement, then the game will jump around in weird ways. The game thought you were 8 frames ahead of where you were and has to load a save state to be in a different position.
>then the game will jump around in weird ways
That's if you configure it badly. You're supposed to actually test the number of real input lag frames by pausing the emulation, holding a button that has an instant effect then advancing frame by frame to count how many frames of input lag and configure it properly. You can't use the same amount of frames for any game
No, it's what happens when the game runs ahead of where it actually is. The more frames you add, the bigger the problem is. Also it doesn't do anything emulator lag, only lag from the game itself.
It can't predict the future. Which is what it would have to do in order to do what you think it does.
You don't understand how runahead works. When you press a button, it basically presses it in the past then fast forwards it. If you configure it to go too many frames back, it will do fricked up shit, but if you configure it correctly nothing weird will happen
Yeah thats why its called runahead and not rollback, but whatever. Think for a second. It has to be a certain amount of frames ahead right? And when you input, it goes back right? So let's say you're removing 3 frames of game lag, it has to load a state from 3 frames before what it is processing. Which means there is 3 frames discrepancy that happens whenever you press any input.
It may be less noticeable if you apply exactly the same amount of runahead frames as the amount of frames that the game requires to process input, because it might not skip animations. But there will be position skips.
Try playing a platformer with 5+ frames of lag. Go forward as fast as you can, and then reverse direction suddenly. There WILL be weird skips happening. If the skips didn't happen, runahead only works for one input and would seem as though it paused for a few frames.
The only way those skips can be avoided is by predicting when you press an input, otherwise there will always be discrepancies between the state you see and the state when you press an input. It can't predict the future, so there will always be skips. The only other way would be to run the game with every button and every possible combination of buttons however many frames ahead you select, then it would be able to act as though you pressed that button. But that would fricking rape performance and we're nowhere near the point where that's feasible for anything other than very basic emulators.
Backwards, forwards, it doesn't matter. You can't overcome this.
Runahead is only supposed to be used to remove lag that's consistently present in the original game. There are no skips if used this way.
Okay then. So explain how it avoids the obvious problem that you didn't press the button how ever many frames before you actually pressed the button.
It won't skip animations or sounds if you set it to the correct value. But that doesn't mean it knows what you are going to do before you actually do it.
Some games have an innate amount of input lag due to how they're programmed
They don't react to the button you press the next frame but rather one or two frames later
They don't do anything input related so nothing changes during these frames
Runahead makes you press the button a frame or two earlier
There's no frickup unless you don't configure it properly
I know about processing time in games. JFC, that doesn't change the fact that you didn't press the button a certain amount of frames before you pressed it.
What you are seeing is how ever many frames you set runahead to ahead of where it would normally be. So that means whenever you make an input, there will be a discrepancy between what you are seeing and what the emulator is processing.
Holy shit you're moronic
Runahead doesn't make you press buttons in the future, it makes you press buttons in the past you fricking idiot. It keeps a savestate of two frames earlier then makes you press the button and fast forwards to the present
EXACTLY. How are you not getting this? There's a difference between the state of the game 2 frames it fast forwards after you pressed the button, and the 2 frames the game runs ahead.
I didn't say it presses the buttons in the future, I said the emulator can't predict what you are going to press in the future. Fricking hell, and you're calling me moronic?
You really don't understand how runahead works and you've never tried it configured properly
As
said, it removes the lag present in the actual original games. Tons of NES and SNES games react to your input a frame or two late, so this basically makes you press a button a frame earlier in the past. It doesn't create any frickery if you set it up correctly and don't exceed the actual number of lag frames
>setting runahead to 8 frames
wow you're moronic
And you couldn't see that I was deliberately discussing an extreme example, so who's actually moronic here? There aren't many games with 8 frames of lag, but they do exist. I don't know of any retro examples, but Street Fighter V has 8 frames of input lag.
The guy I was replying to was talking about a game with 5 frames of lag. So assume I said 5 frames instead. The point was to use an extreme hypothetical, but whatever. Let's stick to known real world examples because you can't wrap your head around hypotheticals.
Nta, and I created a copypasta explaining it, but can't find it (I'm a moron). In short, runahead deals with *internal* lag, something inherent to the game that happens even with real hardware and a CRT. Making the game prone to bugs or lower lag mitigation, plus altering its sequential logic, making it feel easier and different.
For exemplification, think of a fat dude. Instead of going to the gym, he instead decides to lower Earth's gravity, so he feels lighter, even though his mass is still the same. That's a bit similar to the effects of runahead, since it doesn't tackle the main issue, but alters the experience to achieve a perception of improvement. RetroArch does have measures against *external* lag, which helps a lot without side issues (except increasing computional power). If you're interested, tell me and I'll post a pasta I created.
Software emulators will always inherently increase worse-case latency because they have to make sure that the CPU they emulate doesn't run too fast. To do this, they have to slow it down from time to time. If your input happens during one of those pauses it's not gonna start to be processed until the emulated CPU starts running again. FPGA-based emulators don't have this problem because they can just set the FPGA to run at the correct frequency.
This is some rotational velocidensity bullshit.
>rotational velocidensity
can I get a quick rubdown on this
Hearing the difference now isn't the reason to encode to FLAC. FLAC uses lossless compression, while MP3 is 'lossy'. What this means is that for each year the MP3 sits on your hard drive, it will lose roughly 12kbps, assuming you have SATA - it's about 15kbps on IDE, but only 7kbps on SCSI, due to rotational velocidensity. You don't want to know how much worse it is on CD-ROM or other optical media. I started collecting MP3s in about 2001, and if I try to play any of the tracks I downloaded back then, even the stuff I grabbed at 320kbps, they just sound like crap. The bass is terrible, the midrange...well don't get me started. Some of those albums have degraded down to 32 or even 16kbps. FLAC rips from the same period still sound great, even if they weren't stored correctly, in a cool, dry place. Seriously, stick to FLAC, you may not be able to hear the difference now, but in a year or two, you'll be glad you did.
This is a real thing or am i being trolled? that sounds insane.
Assuming you're being legit, does pirating games i own fix the problem? As in, would pirating Ape Escape be better than playing my actual disc i had from childhood?
different gay but its all completely true
>would pirating Ape Escape be better than playing my actual disc i had from childhood?
it might buy you some time
but it all returns to dust eventually
Your answer just takes one Google search, try deleting System32 while you're at it.
Forgot to have a nice day, homosexual! I know you've been told to do this multiple times daily, just get it over with!
That's so interesting. Definitely going to look up this shit. I've always heard mp3 is bad but never for this reason
That's why lossless is so important. So you never lose it
Yeah I should have had them professionally transfered to cds, that would have gave me some more time before disc rot started to set in to find a better preservation method but the cost would have been astronomical and it would have only given me 2 tracks for every tape and record. All I knew at the time was MP3s were the future but so were zipdisks not long before that. Getting information for progressing technology back then was ridiculous but mo3 had been out for a few years at least so I figured they worked the kinks out.
I ripped some vintage jazz records and a lot of college/alt rock tapes I got from trading back in like 1999 and encoded them as mp3. Don't even think flac was an option. Terrible mistake, waste of time, they're unlistenable now. Worst mistake I made though was backing up my old ide drives to new sata drives and not checking on the recordings, completely garbled them.
>This is a real thing or am i being trolled?
Tell me you were born after the year 2000 without telling me you were born after the year 2000
Christ you newbies are unreal
Sure, let me just take care of this side fumbling, brb
keep the shilling to your thread dude
From personal experience, Dolphin indeed has more input lag than most other emulators I use. And it doesn't even support run ahead, natively at least
So the advantage of emulation is input lag. Maybe you own the input lag and not the game.
I play GameCube games on my softmoded Wii u via its 480p gamepad. CRTs can look nice but progressive scan will always be superior
>I play GameCube games on my softmoded Wii u via its 480p gamepad.
Same. Very comfy.
>not playing at 480p on a CRT monitor
If you have a powerful enough computer, use the retroarch core and enable runahead
I am a very good Super Monkey Ball player (consistent 1cc master without pause etc.) and I'm pretty confident that Dolphin on a CRT is basically indistinguishable from playing on a console aside from the audio issues.
you are right, visual latency is definitely minimal but audio lag is totally real in a far more dignificant way
I feel like people sleep on audio latency for sure. Like, sure, it doesn't quite frick up the game outside of shit like rhythm games, but it still takes me out of the experience if the lag is beyond 64ms or so. This is one place where RetroArch actually does super fricking well compared to many standalones and has for a long time, and it doesn't get enough credit for it.
>Like, sure, it doesn't quite frick up the game outside of shit like rhythm games
False. Have you ever played a shitty Sanic port where the jump noise plays at the height of his jump rather than the start?
>This is one place where RetroArch actually does super fricking well compared to many standalones
If your PC can handle it, you can go as lower as a single frame of input and audio lag (in modern screens). I don't know of any case going lower than that, except with the use of a CRT, but that beats the convenience out of the process.
In Super Monkey Ball specifically the audio lag doesn't matter at all because no one in their right mind would actually use the audio cues for anything.
If you're playing Melee and audio sensitivity actually matters, you can cut it down a fair bit by using WASAPI, but it's still not perfect.
>is it just me?
Genuinely could just be your machine. I tried running dolphin on two different computers a couple years ago to check if the lag I felt was just because I was using a weaker machine, and it was. Worked fine on the faster one.
Might want to ask /emugen/ on /vg/, or the official dolphin discord that I assume exists, about possible settings you could change.
Don't even bother with /emugen/ it's usually cancer. I think dolphin has a reddit that they run and some of the devs or contributors hang out there just to answer questions.
>/emugen/
It's a worthless schizo haven now. Unironically /vr/ is a better place to discuss emulation. Shit, I'd sooner go to /r/emulation.
>emulation
found the problem sir
you were pretending to play the game instead of actually owning the hardware and playing it
WAS EVERYTHING A LIE??? I CAN'T BELIEVE IT!!!
Try without vsync.
>another just emulate bro gay btfo
Lol
Lmao
Most 4th gen onwards emulators add in 4-5 frames of input lag, try playing any latency sensitive games on the same CRT first via console then emulation. Games I generally use to show people the differences include: Gran Turismo III, Tekken Tag/4/5 (the same combo that's easily doable on console has a slight chance of being whiffed until you make the latency adjustment)
Pretty much any fighting game you can do combos in is a great way to test.
I agree, the input latency on Dolphin can be quite bad. Especially on Steam Deck, where capping the refresh rate to the game's framerate and enabling vsync and turning off "skip duplicate frames" is basically mandatory to achieve good framepacing.
Well it is true that some emulators add some input lag, I've never experienced something as crazy as some people make it out to be (like saying it's 4-5 frames)
The first thing you should do is make sure of these things
>disable desktop composition
>go to your graphics card control pannel and for the emulator, disable all unnecessary shit and set to low latency mode
>disable vsync
>make sure you're not using a pad that's a piece of shit. If you're using some 10 bucks knock off pad or some chinese USB adaptor that cost 3 bucks, then you're probably getting 2-3 frames from that thing alone.
Only after these things should you even consider runahead; but if all else fails, yes, use it, but it should be for 1-3 frames max
they make some programs that let you increase the response time of your GC controller adapters. But even on Faster Melee/Slippi there is noticeable input lag, you realize this when switching to a CRT and feeling the responsiveness
>Try playing a platformer with 5+ frames of lag. Go forward as fast as you can, and then reverse direction suddenly. There WILL be weird skips happening. If the skips didn't happen, runahead only works for one input and would seem as though it paused for a few frames.
You seem confused. Weird skipping can only happen is if you run TOO FAR ahead. The goal is to run just far enough to grab the rendered frame that accurately reflects the game state of your most recent input.
That image is in relation to animations. Its also depicting the character standing still.
I'm talking about momentum changes. I'm talking about what happens if you press a button after jumping on an enemy for example.
I understand how to determine a games lag and set runahead, I know how it works. It still has problems. If you don't notice, then good for you, I'm happy for you. But I do.
You clearly don't know how it works if you think it affects "momentum" any differently from standing jumping.
>Hypothetical example: if while moving it takes 7 frames of game logic to skid to a stop, but it takes 3 frames for the first frame of skidding in game logic to be shown on screen, then it would take 10 frames for it to visually recognized you stopped.
>If you were to run ahead and remove those 3 frames, it doesn't change the fact that you see all 7 frames of game logic skidding, and therefore it feels the same.
>if you set runahead to be something obviously too large like 6 frames, you would only see the final 4 frames of the game logic skid... assuming you perfectly skid for 7 frames and then let go, you would see 3 frames of your character starting to reverse course before snapping back, which is a clear sign that you've set the run ahead to an incorrect value.
It's the other way around. Momentum effects it. It doesnt effect momentum.
At this point I've realised I'm dealing with absolute fricking morons who can't read. Which seems like it would be a real hinderence on a website that's 99% reading. But there you go.
You can stop rehashing the bsnes article now.