It is currently Thu Mar 30, 2017 1:45 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Input lag in emulators
PostPosted: Fri Mar 10, 2017 1:49 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1110
Has anybody ever measured the input lag of emulators in relation to the real hardware?

When it comes to input lag within the same emulator according to different configurations, it's pretty easy to check:

  • Set your monitor to 60 Hz.
  • Map a visible action (like a jump) to one of the keyboard keys that have an LED: Num lock, caps lock or scroll lock.
  • Take a video camera that can record in 60 FPS. Point it at the screen, so that the screen and your keyboard are visible at the same time.
  • Press the key to perform the action on the screen.
  • Watch the video frame by frame and count the frames between the LED lighting up and the action on the screen becoming visible.

With this method, you will realize that vsync in Direct3D fullscreen has about three frames of lag in relation to any configuration without vsync.
For some curious reason, Direct3D window mode, DirectDraw window mode and DirectDraw fullscreen all have only 0 to 1 frame of input lag when vsync is enabled.

This of course still doesn't say anything about the absolute input lag. For this, you would need to put an LED on the actual controller and use the same TV/monitor as for checking the emulator lag.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Fri Mar 10, 2017 3:36 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 880
Writing a test program to execute in the emulator instead of using an existing game may work a bit better since some games may not respond immediately. You should then also add something into the test program to alter the picture on the screen every frame regardless, in order to notice the synchronization of the frame. And then also the display lag, music lag (so, include sounds too), and in case of any possibility of any lag of the operating system or BIOS to turn on/off the lights on the keyboard (although that is likely to be fast compared to the video, I think).

_________________
.


Top
 Profile  
 
PostPosted: Fri Mar 10, 2017 3:44 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18005
Location: NE Indiana, USA (NTSC)
Did somebody say test ROM?

This one reads the A button continuously, as in multiple times per frame.


Attachments:
a-white.zip [2.55 KiB]
Downloaded 7 times
Top
 Profile  
 
PostPosted: Fri Mar 10, 2017 4:08 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1110
zzo38 wrote:
Writing a test program to execute in the emulator instead of using an existing game may work a bit better since some games may not respond immediately.

tepples wrote:
Did somebody say test ROM?
This one reads the A button continuously, as in multiple times per frame.

Huh? In how far would such a program be more helpful than a regular game?
It's about measuring the time between button press and action on an emulator vs. on a real console and then looking at the difference.

Even if you say "Super Mario Bros." has a delay of one frame between input and action which the test ROM doesn't: Why is that important for a console vs. emulator comparison? Even if the delay was five seconds, it wouldn't matter since it's only about the relative difference:
If, for example, the NES produces input lag of five seconds while the emulator produces input lag of five seconds and two frames, you would know that the emulator is two frames slower than the NES.
You would get the same result if you measured a lagless test ROM on an NES vs. on an emulator: The difference between NES and emulator would still be two frames if it was two frames with the normal game, wouldn't it?

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Fri Mar 10, 2017 5:27 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3795
I still think the Time Travel method is the neatest idea for eliminating input lag. That's where you undo several frames, then re-run them as if they had different input. Often times, you would get audio or visual irregularities from that, as a sound effect would start, and an animation would start to play.
But just one frame for time travel would be enough to eliminate the internal lag that's part of games themselves.

The neat thing about Mike Tyson's Punch out is that while it is one of the most lag-sensitive games, you could literally backdate all actions by 3 frames, and you'd never notice any irregularities in the animations. It takes 5 frames of internal lag before your left/right dodges animate, and 3 frames of internal lag before the crouching or punching animation starts.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sat Mar 11, 2017 3:46 am 
Offline

Joined: Sat Aug 28, 2010 9:01 am
Posts: 151
The reason to make a dedicated test ROM would in my opinion be two-fold.
1) Guaranteed behavior. some games may for whatever reason not react consistently to input and might have lag in some states but not others, skewing the test. This is conjecture on my part, but it would be better to eliminate the risk entirely.
2) A test ROM could indicate that a button was pressed in a more obvious way. For example, it could change the background color so you don't have to track a 1-2 pixel movement of a sprite.

Besides, it might be worth investigating if there's any delay before the caps lock LED turns on. Is that handled internally in the keyboard, in modern keyboards? Or must the OS first register the keypress, and ask the keyboard to light the LED in the next USB transfer? This may not matter for comparing different graphics APIs, but might give a too optimistic result for the PC, when comparing to a console.

_________________
Gameboy Genius (Blog) - Gameboy development forum (+wiki and file area)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group