Inherent SNES console "lag" test on a CRT

[Harrumph]

I thought this could be interesting to some (didn't see any post about this here before). Brunnis on Libretro forums has tested SNES (actual console) input lag using a controller with a hardwired LED, and filming at 240 fps on a CRT. To me, the resulting delay in character movement after button press was surprisingly high. For SMW2, the average delay was 3.6 frames. I'd have expected this to be more like 2 frames.

In view of this, emulators managing 4-5 frames of lag for SNES are actually not doing too badly...

The author noted that some games have less lag, e g he claims Super Metroid had 1 frame less lag than noted above.

https://forums.libretro.com/t/an-input- ... n/4407/424

Original post, which summarizes and links to all his other test posts:
https://forums.libretro.com/t/an-input- ... ation/4407

Note that this is not intended to start some flaming debate over the use of emulators, but I'm thinking many (like myself) might have overestimated the "laglessness" of playing a real console on a CRT (at least for the SNES).

[Ryoandr]

4 frames isn't uncommon. CPS2 test yielded 4 frames of delay also.

[Sumez]

The author noted that some games have less lag, e g he claims Super Metroid had 1 frame less lag than noted above.

It would probably be better to test with a menu or similar, since hardcoded "lag" in the game logic shouldn't count towards hardware performance. The Mario games have a lot of inertia, and it's not unsurprising that Mario takes a while to move. Some games even have a good reason to delay reactions to sideways motion if they are supposed to react differently to diagonals, etc.

[Makinx]

Note that this is not intended to start some flaming debate over the use of emulators, but I'm thinking many (like myself) might have overestimated the "laglessness" of playing a real console on a CRT (at least for the SNES).

No one overestimates the laglessness of a CRT, because the crt itself doesn't cause lag as opposed to LCD tv's. The lag you describe is caused by either the console or the game. Most likely the game itself has a slow response time due to way it is programmed and the input delay is worse because he tested on a pal console, something the tester doesn't seem to consider as he theorizes about electron beam movement and such.

This is a pretty poor test setup anyway to draw any kind of useful conclusion from. I'm sure if he tested Lester the Unlikely his results would be a lot worse and his flawed conclusion would be that the snes has terrible input delay.

[Xer Xian]

The guy tried to measure the lag difference between two setups. While the testing methodology isn't perfect since the display and controller vary (but one could argue that they should change, because they are strongly associated with the different hardware source), it's adequate for that purpose. It would have been nice if the author uploaded the video though.

[Blair]

so this is essentially measuring the input lag of various game engines on the super Nintendo? otherwise they would be using the super Nintendo version of the 240p test suite as I believe that has built-in input lag testing without the added variables of an underlying game engine.


since we (end-users) can only control a few variables in our set-up, to minimize input lag best we can. (main display, secondary image processor, input device, vsync settings). outside of a few rare instances of modification there isn't much we can really do to affect the input lag of most game engines. as I recall digital foundry and Linus media group both did small investigations into a few different game engines and found that some AAA games (call of duty, battlefield, crisis) could have nightmare scenarios of over 90ms - 120ms of input lag (even in off-line single player player scenarios!) so even if you do your best to completely eliminate input lag with your display and hardware you are still likely going to have to deal with a potentially crazy amount of input lag just because of the way modern games are coded.

older generations of videogame don't have the same problems with input lag but they still probably have some depending on how the physics are programmed, what the frame rate is like, if its a port, what genre it is, etc.

[Fusion916]

I think already articulated in this thread, but any "lag" on a crt is due to the game itself, not the setup.

At least these tests should yield near identical lag on any generic SDCRT that doesn't have some strange on chassis post processing like some late HDCRTS did.

[darcagn]

Even if standard CRTs did have a frame or two of lag, that frame or two of lag would then become the ideal. First, these games were designed to be played with the exact specs of a standard CRT, so any game engines would be "calibrated," so to speak, for gameplay at that level of lag. Just like the lag of an HDTV would throw off a gamer used to a CRT, if it were possible to have less lag than a CRT, that too would throw off a gamer. Second, the timing of early light-gun games depends specifically on the timing of a CRT. Duck Hunt, for example, requires frame-specific timing; 1 frame per duck on screen is blacked out with a light square on that duck. The gun must read the light level at that exact frame in time. If we somehow reduced that lag, the game would no longer work. And the fact that Duck Hunt works on all standard CRTs is evidence that all standard CRTs have the same frame timing.

[Harrumph]

No one overestimates the laglessness of a CRT,

I think already articulated in this thread, but any "lag" on a crt is due to the game itself, not the setup.

The point of the test was never to measure any CRT lag, on the contrary, the premise of the test is that the CRT does not produce additional lag and thus the lag measured is due to the console+game. I was surprised by the amount of lag inherent to the console (or at least the game tested, SMW2, it would ofc have been really nice to see additional games tested), perhaps others weren't so surprised.

so this is essentially measuring the input lag of various game engines on the super Nintendo? otherwise they would be using the super Nintendo version of the 240p test suite as I believe that has built-in input lag testing without the added variables of an underlying game engine.

Right, it might be more correct to call it SNES game engine lag, as it seems to be variable depending on the game. Brunnis did test the SNES 240p suite on emulators, and it showed 1 frame less lag than SMW2, probably that relation of game processing time vs 240p suite processing time is still present on actual hardware, but of course it's unknown to me if this is the absolute minimum processing time that a real SNES can achieve.

Additionally, I thought I might post the links here because (iirc, I might be misremembering here) both RetroRGB and Voultar has been talking about one day use this type of test setup (controller hardwired to a LED), but didn't get around to it yet, afaik. Maybe they'd get inspired to try it now, and extend it to a bunch of other consoles and try more games.

[orange808]

The minimum SNES latency time would be difficult to measure because it is very small.

The SNES doesn't concern itself with thread safety or power consumption; USB input has its own independent layer of implementation--with a library to expose controller input information to external processes. USB is convenient, programmable, and adds considerable overhead and latency.

The SNES makes the state of the controller directly available; programs simply poll the registers for the controller. The only limit on latency is the design of the game loop and the timing of the vblank.

[ChuChu Flamingo]

I think already articulated in this thread, but any "lag" on a crt is due to the game itself, not the setup.

At least these tests should yield near identical lag on any generic SDCRT that doesn't have some strange on chassis post processing like some late HDCRTS did.

Pretty much this. Although rare, there have been confirmed reports of late gen CRTS that are SD lagging. They must be using some type of post processing.

The lag Harrumph is talking about is due to how a console processes the games video and input regardless of the screen it is using. I would consider this lag to be the base input lag and it can vary quite a bit depending upon the game.

I wonder if it is possible to have less input lag on emulation of a game than on actual hardware due to fewer limitations.

[Star1]

I wonder if it is possible to have less input lag on emulation of a game than on actual hardware due to fewer limitations.

Short answer, no, there are more limitations, not fewer.
https://byuu.org/articles/latency/ this article explains the issues emulators have to deal with

[tomwhite2004]

Short answer, no, there are more limitations, not fewer.
https://byuu.org/articles/latency/ this article explains the issues emulators have to deal with

Not all emulators....

https://forums.dolphin-emu.org/Thread-b ... e-scenario

[Tatsuya79]

I wonder if it is possible to have less input lag on emulation of a game than on actual hardware due to fewer limitations.

Short answer, no, there are more limitations, not fewer.
https://byuu.org/articles/latency/ this article explains the issues emulators have to deal with

It explains it's his own limitation to not notice a 16ms difference and that his emulator didn't care about vsync.
He's making some rules that concern his emulator only and his own goals.

You're free to do whatever you want in your own emulator and even hack into the games code to reduce the lag if you can.

[Star1]

Alright, I stand corrected That said, are there any faster than real hardware snes emulation options?