MiSTer FPGA Forum

I guess the goal for a lot of MiSTer users is to get as close to the original experience as possible, and reducing frames of input delay is one of the key elements.

I read somewhere that when you rotate the view instead of the screen it adds additional frames of input delay -- is this correct and does anyone know the exact number?

I've also been enjoying tinkering with the various CRT filter options, and some of them look really great. In traditional emulation I've been told to always keep filters OFF since they can add additional lag. Is the same true on MiSTer?

Any more parameters to consider when trying to reduce input lag?

As I understand it, if you use a CRT, either via the analog I/O board or through Direct Video, and you don't engage the scaler, you have 0 display lag. What you see on the CRT happens at exactly the same time that you would have seen it on real hardware on a TV.

Depending on your controller and how it connects, you may have control lag, which is a different thing; this is how long from when you make an input to when the signal arrives so that it's visible to the core. On any USB controller, there's a 1ms poll rate, so your average response time is a half-millisecond. From there, you add any hubs, any wireless lag, and any controller lag. My DS5, for instance, apparently has about 2ms of control lag in wired mode, which is how I use it. There are a few that are even faster. There are many many that are much slower, especially in Bluetooth mode. The 8BitDo Pro 2 Wireless has 16ms lag in Bluetooth mode, for instance, a whole frame. And there are controllers that are even worse.

If you use SNAC, your input lag is about zero, but SNAC controllers only work in cores, they don't work in the main Mister menus. Because of that, I tend to think you should use SNAC only for lightguns. A fast wired controller is so quick that you don't gain much from a SNAC joystick.

Display and input lag are usually additive, but not always. If you have to see something and then react to it, they add. But if your reflexes are good enough and you can anticipate what will happen, they can sometimes run in parallel.

Ok, so, that's the best case; 0 display lag, possibly 0 controller lag, maybe 3 or 4ms if you have a fast wired USB controller.

If you engage the Mister scaler on the analog port, in the fastest/least compatible mode (vsync_adjust=2), you add four display lines of lag. This is largest on lower resolutions; at 320x200, if my math is right, that's about a third of a millisecond. At higher resolutions, it's faster. I don't think rotation adds any lag, although I could be wrong. I also think CRT filters are free, but I don't have actual hard knowledge of this. If anyone contradicts me, they're probably right.

You shouldn't need them on a CRT, but more compatible Mister scaler settings add more lag; vsync_adjust=1 is, I think, one frame of lag, and vsync_adjust=0 can be two. You want a display device that supports vsync_adjust=2 for best results. I believe most CRTs do just fine with it. It's flat panels that can be troublesome.

On any flat panel, you will add at least a little lag. In minimum-lag mode, the LG C2s add about 2ms to a 1080p signal. (but like 16ms lag for any 4:3 signal, so beware.) Most flat panels add at least 5ms, and 10ms is pretty common. TVs in modes intended for watching video can have very long lag times... those same LG panels are like 80ms lagged when not in Game mode. They're doing a lot of internal processing to try to improve the signal, and while they generally succeed, the output is way behind a CRT. This doesn't matter in the least when watching a movie, but you'll care a lot about it when playing Punch Out. And, again, your vsync_adjust mode will add lag as well... the Mister scaler is always engaged on an HDMI signal. Flat panels that can support vsync_adjust=2 are much better.

The output device you choose, in other words, the mode it's set to, and the Mister scaler mode it supports, all matter a lot. A CRT with no scaler running is the best you can possibly do.

Arbitrary Function wrote: ↑Tue Jan 10, 2023 8:12 am

I read somewhere that when you rotate the view instead of the screen it adds additional frames of input delay -- is this correct and does anyone know the exact number?

I've also been enjoying tinkering with the various CRT filter options, and some of them look really great. In traditional emulation I've been told to always keep filters OFF since they can add additional lag. Is the same true on MiSTer?

Any more parameters to consider when trying to reduce input lag?

hey there!

its been discussed on the discord and confirmed by others that if youre rotating the image from the original orientation from the MiSTers core menu, it is adding a 1-frame buffer to accomplish this. if the screen rotation is built into the dip switches of an arcade core, or a menu in the actual game youre playing, then it is not adding any input lag.

as far as the CRT filters in the video processing menu of a MiSTer core adding lag, it is in the similar range of vsync_adjust=2 (something very much imperceptible).

daemonbyte adapters for an arcade controller or original controllers will be 1ms or less on average, and most modern TVs are adding 9-12ms of input lag over HDMI.

there are some handheld MiSTer cores that have video buffering modes, but those are also in a very low range of lag, similar to the video processing options.

and all of that is to say, if you arent going for 1CCs in a SHMUP, beating mike tyson on NES, or running kaizo mario, you wont notice the lag. but if you are trying to do those things, you will want a fast computer monitor with HDMI or a CRT

Don´t forget about our stupid brains and reflexes that can add lag too

Imho a lot latency or lag is overblown and a lot of these old systems were not latency free to start with for example a original SNES had up to 72ms or 3.6 frames of latency on a CRT

Systems like PS1 the frame times are all over the place at times as would be the latency

Using USB with MiSTer it's hard to notice any additional latency even on a LCD when using V-mode 2

But not the hardware itself. The lag was programmed into the games. Super Mario World has 2-3 frames of lag iirc. Most 8bit games (after the VCS Generation) had mostly 1 frame, later 16bit games 1-2.

Retro-Nerd wrote: ↑Wed Jan 11, 2023 7:05 pm

But not the hardware itself. The lag was programmed into the games. Super Mario World has 2-3 frames of lag iirc. Most 8bit games (after the VCS Generation) had mostly 1 frame, later 16bit games 1-2.

I wouldn't say the lag is programmed more a side effect of a combination of code and hardware.

The SNES CPU was pretty poor and the cause of the slowdowns it had a 16bit instruction set but only a 8bit data bus. This is why we saw various in cartridge accelerators

Latency is just one of those things even in modern gaming.
We see companies marketing 600fps as selling point but without also saying there's no real gain in latency from 144fps due to GPU frame to frames.

I don't think so. I've seen 8bit games with 2-3 frames lag too. It's intended imo.

Arbitrary Function wrote: ↑Tue Jan 10, 2023 8:12 am

I read somewhere that when you rotate the view instead of the screen it adds additional frames of input delay -- is this correct and does anyone know the exact number?

The reason there is at least 1 frame of lag when you virtually rotate an arcade screen with a scaler or an emulator instead of physically rotating the screen is because when the physical screen gets drawn in landscape mode, the scan line moves across the screen, left to right a line at a time and goes down the screen from top to bottom. If you physically rotate the screen clockwise, it now draws a scan line top to bottom starting on the right side of the screen and working its way to the left side as it draws the screen. In order to know what to draw with a virtual screen rotation with the scaler and not physically rotating it, it needs to see the whole drawn picture before it knows how to draw it rotated with the scan lines going in a different direction. I hope that makes sense. Another way to see this is to draw a rectangle on a piece of paper representing a screen. With the rectangle horizontal, start drawing some scan lines from top to bottom, like 3 lines worth. Now rotate the piece of paper 90 degrees and this represents the scaler virtually rotating it to vertical on your horizontal display. How do you know how to draw the empty area on the left side with left to right scanlines going line by line from top to bottom if there is no picture information there yet to know what to draw on the non-physically but virtually rotated screen based on three scanlines way over on the right side giving you a different area of the picture that you don't need yet. Hope that makes sense. Once the whole frame is drawn right to left, then you know how to draw in the new orientation from top to bottom.

Grumpy-Old-Gamer wrote: ↑Wed Jan 11, 2023 6:20 pm

Imho a lot latency or lag is overblown and a lot of these old systems were not latency free to start with for example a original SNES had up to 72ms or 3.6 frames of latency on a CRT

Any latency inherent to the console will be known to the devs and compensated for with game design. But they didn't know about flat panels, and won't be considering either input or display lag in their design. To whatever degree you add those, you make reflex games harder.

Systems like PS1 the frame times are all over the place at times as would be the latency

Again, working as intended. Adding additional lag to what they tested for is never a positive.

Using USB with MiSTer it's hard to notice any additional latency even on a LCD when using V-mode 2

If you're using a good, low latency controller, with a fast LCD, it is very hard to tell the difference. But some controllers really suck, especially in Bluetooth mode, and some displays are dismal. LG C2 OLEDs are like 2ms in Game Mode with the PC input type, for example, but over 80ms in movie mode.

A Daemonmbite adapter in 1000Hz polling mode is just fine. Most USB wired or wireless 2.4Ghz controllers shouldn't add too much lag.

The regular USB ports also do 1000Hz polling if you set them to. The original controllers you can plug into the Daemonbite shouldn't add any latency, but most USB controllers add at least some. The DS5 (what I'm using) is under 2ms. The 8BitDo Pro 2 Wireless is about 6ms in wired mode, but about 16ms in Bluetooth mode. There's lots more measurements at the lag database. I'm too lazy to look up the URL right now.

It's surprising how many laggy USB controllers are out there.

Malor wrote: ↑Wed Jan 11, 2023 10:49 pm

It's surprising how many laggy USB controllers are out there.

The DualShock 3 is particularly laggy compared to other Sony controllers, even wired.

Disappointing as I have 4 of them and they work well for the PS1 core, being quite close to the DS1 form factor.

I'm not super enamored with the size of the DS5, it doesn't fit my hands that well, but I definitely like the low latency. What I really wish is that 8BitDo did better engineering, because the Pro 2 Wireless is probably the most comfortable joystick I've ever had... while simultaneously being the least reliable by a couple orders of magnitude. And its latency is kinda bad, too.

Malor wrote: ↑Wed Jan 11, 2023 10:41 pm

Grumpy-Old-Gamer wrote: ↑Wed Jan 11, 2023 6:20 pm

Imho a lot latency or lag is overblown and a lot of these old systems were not latency free to start with for example a original SNES had up to 72ms or 3.6 frames of latency on a CRT

Any latency inherent to the console will be known to the devs and compensated for with game design. But they didn't know about flat panels, and won't be considering either input or display lag in their design. To whatever degree you add those, you make reflex games harder.

Systems like PS1 the frame times are all over the place at times as would be the latency

Again, working as intended. Adding additional lag to what they tested for is never a positive.

Using USB with MiSTer it's hard to notice any additional latency even on a LCD when using V-mode 2

If you're using a good, low latency controller, with a fast LCD, it is very hard to tell the difference. But some controllers really suck, especially in Bluetooth mode, and some displays are dismal. LG C2 OLEDs are like 2ms in Game Mode with the PC input type, for example, but over 80ms in movie mode.

PS1 variable or low frame rates was not always intended it was a by product of being CPU limited and we can see with the Turbo or X2 CPU core in MiSTer how a lot games could perform without affecting the game logic but depends on engine. Some frame rates on a stock PS1 are very poor. This is not something you can factor in to game design a lot of times they were just trying to get the most FPS they could and this is why we saw so many techniques used on the PS1 to keep the FPS high like short draw distance, lots of corners on snaking maps, small rooms. Games drawing into infinity or large open vistas didn't happen until PS2. Some Devs were just trying to be too ambitious

So the latency will be all over the place unintended and this issue carried on as once we had to rely on GPU frame to frame times it just introduced another source of latency. Even latency in modern gaming is held back by frame times even though we are pushing ludicrous FPS

This is why later console generations mid 90s onwards were not cycle accurate and why software emulation is a good option for these systems

Grumpy-Old-Gamer wrote: ↑Thu Jan 12, 2023 7:56 am

PS1 variable or low frame rates was not always intended it was a by product of being CPU limited and we can see with the Turbo or X2 CPU core in MiSTer how a lot games could perform without affecting the game logic but depends on engine. Some frame rates on a stock PS1 are very poor.

So the latency will be all over the place unintended and this issue carried on as once we had to rely on GPU frame to frame times it just introduced another source of latency. Even latency in modern gaming is held back by frame times even though we are pushing ludicrous FPS. FPS and frame to frame times so latency are non linear. So we see the likes of Nvidia pushing 600fps, marketing low latency tech like reflex but their own marketing graphs prove they are still at the mercy of frame times

This is why later console generations mid 90s onwards were not cycle accurate and why software emulation is a good option for these systems

I assure you those console CPUs still had cycles.

Cycle-accurate is a property of emulators/FPGAs... trying to match CPU cycles.

Of course no dev "intends" low framerate or variable lag but, if they know that's how their game runs, they can compensate for it. Classic Mario on 2D consoles demands frequent, precise micro-corrections. Celeste on modern systems adds "coyote time" so you can run off a ledge for up to 5 frames and still make a jump. Each was designed for their native environment. If you aren't replicating that environment the experience may differ.

FoxbatStargazer wrote: ↑Thu Jan 12, 2023 8:52 am

Grumpy-Old-Gamer wrote: ↑Thu Jan 12, 2023 7:56 am

PS1 variable or low frame rates was not always intended it was a by product of being CPU limited and we can see with the Turbo or X2 CPU core in MiSTer how a lot games could perform without affecting the game logic but depends on engine. Some frame rates on a stock PS1 are very poor.

So the latency will be all over the place unintended and this issue carried on as once we had to rely on GPU frame to frame times it just introduced another source of latency. Even latency in modern gaming is held back by frame times even though we are pushing ludicrous FPS. FPS and frame to frame times so latency are non linear. So we see the likes of Nvidia pushing 600fps, marketing low latency tech like reflex but their own marketing graphs prove they are still at the mercy of frame times

This is why later console generations mid 90s onwards were not cycle accurate and why software emulation is a good option for these systems

I assure you those console CPUs still had cycles.

Cycle-accurate is a property of emulators/FPGAs... trying to match CPU cycles.

Of course no dev "intends" low framerate or variable lag but, if they know that's how their game runs, they can compensate for it. Classic Mario on 2D consoles demands frequent, precise micro-corrections. Celeste on modern systems adds "coyote time" so you can run off a ledge for up to 5 frames and still make a jump. Each was designed for their native environment. If you aren't replicating that environment the experience may differ.

The issue comes with 3D rendering and GPUs. The CPU can hold back GPU draw calls, there might be too much work placed the on CPU or the GPU for a frame or number of frames and the early days even 3D was highly single threaded which didn't help either, we have only moved to multi threaded graphic APis in the past ten years for example

With 2D consoles and computers Devs knew exactly how many clock cycles and how much rastertime they had per frame interval
But even later consoles like the SNES performance was hampered by the choice of CPU. Powerful and advanced custom graphics processor paired with a biscuit CPU based on the old MOS 6502, send too much work to the CPU and it caused the infamous slowdowns.

But, again, adding more latency is never an advantage. It's just straight worse than running on original hardware. There is no case where additional display or input lag is helpful.

It seems to me that super low latency just "feels good". Totally unscientific, totally subjective, maybe placebo, but its like my lizard brain likes low latency haha. Like a kind of realism or something is added, an immediacy I guess you can call it.