Which consoles would that be? I was (perhaps naively) under the impression that pretty much everything up to and including 16-bit era consoles had no input lag from the hardware side?


@mega post that shows the whole thread from twitter.


Thanks man


SNES and Genesis games.


That’s input lag from the game software, not the console / hardware.


I know it’s kinda trolly but I don’t think it will be the same thing. There is an analog option that doesn’t add lag and we have a solution for analog to digital that doesn’t add lag (ossc). I’m sure people are going to code a better scaler than the one built into the mister Core.

I never got run back working in a uniform way too. If I remember you had to set it up for each core or maybe it was game. Wasn’t ideal and it did mean the user had to use some guess work too.


@tomwhite2004 True, but the important takeaway is that playing on original hardware, in the case of pretty much all games, has this added lag and the MiSTer supposedly doesn’t.

@kawika Run Ahead is easy to set up and there’s no guesswork… although yea it needs to be set up on a per game basis. It shows how in the video I posted yesterday and takes very little time. If you’re not hopping around between new games constantly it’s not so bad! As for inconsistent performance? It’s all a matter of having a good enough computer to use it. Like many other Retroarch settings, it’s expected not to perform identically with all cores and games since some are more demanding than others.


the lag created by a games logic having to take a certain amount of frames to run will still be there on mister too, you don’t and cannot remove it just becuase you are using an fpga.


Alright, then I have to wonder what the guy was referring to in the bolded part or if he’s just wrong.

New scaler cores are being written which should allow for lower lag via HDMI, but two frames is still very low, since the cores themselves essentially have no added output lag (compared to the OG console / computer) before it reaches the scaler


he is correct, the emulated hardware core on its own has no lag. but this variable game logic (for want of a better term!) lag which is what run ahead removes is separate from that. would be interested to know if the same save state manipulation could be done on an fpga clone to achieve the same result.