I've never played punchout before, it's been sitting on my shelf for months now. As such, this probably isn't the best test.

I'm just confused, now. If the total latency is less than human reaction time (200 ms on average), then I don't see how it could possibly make a difference...

25ms is running in game mode with all the enhancements turned off according to displaylag.com. I doubt that the emulator with the configured settings adds more than 1/2 a frame on top of that. This is just based on my subjective experience of having played and tested dozens of games on the thing. I play a lot of twitch games where timing is very important so I would think that I would notice it.

 I think my problem with Adventure Island is that I just need to practice it more...

Some really weird notions in this thread. The current state-of-the-art of NES emulation is better than just about any other console except maybe the SNES (thanks to byuu), so I'm not sure why it's being used as an example of something that's subpar -- even top-shelf emulators for systems like the Atari 2600 and Sega Genesis still have weird compatibility issues and inaccuracies.

And 200ms is an insane amount of lag that would dramatically affect even a casual gamer when playing twitch games like Punch-Out, VCS Kaboom, any number of shmups, etc. I certainly notice that much lag playing Kaboom, or any Atari game, on my sister's midrange LCD. High-end studio musicians are affected by as little as 20ms of lag or less -- Jeff Porcaro could allegedly detect 5ms. It's not as simple as single-event reaction time; it also has to do with patterned behavior, the whole idea of "getting into a rhythm", and a bunch of other parameters.

It still seems to me that there's an easy test for assessing total system lag. Build a ROM that does nothing but two things: turns the screen white, and emits a beep, on controller input. (Have it check on every frame, or even every scanline if possible.)

Then take two contact mics and a video camera. Tape one mic to the controller, near the fire button, and the other one to the speaker you're using. Start recording, boot the ROM, hit the fire button on the controller, and measure the distance between the attack transient (sound) of the button being pressed and the beep coming from the speaker. That's your audio lag, which may or may not be the same as the video lag (it should be, but might not). Finally, study the video feed frame-by-frame to discern the difference between the screen flash and the beep.

Wouldn't that give a reliable absolute number? Then you could toggle every manner of variable to see how it changed things: LCD vs. CRT, emulation vs. real hardware, hard-wired vs. wireless controllers, etc.

I said 200ms of "total latency" not input lag. 200ms input lag WOULD be insane.

"Testing has found that overall "input lag" (from controller input to display response) times of approximately 200 ms are distracting to the user" (http://en.wikipedia.org/wiki/Inpu...)

Please, if you can, point me to an NES emulator that can achieve the following:
-full screen mode, with black bars on the side but not the bottom
-correct aspect ratio (1.143 for NES)
-no screen tearing
-no (or very little input lag)
-very close to perfect accuracy/timing.
-controller support
-no/very little sound issues.

Like I said, I've messed around with half a dozen NES emulators and was unable to achieve all of the above with any of them. Nestopia would be awesome if vsync didn't result in horrible input lag. So you either have to accept horrible screen tearing or horrible input lag. All the emulators I've tried had similar issues. With Fceux I could achieve full screen with no screen tearing and very little input lag, but the accuracy of that emulator seemed really poor and/or it just didn't run well on my machine.

You also perfectly described Blaarg's NES reflex timer. Using it I get a total average time of less than 240 ms using retroarch, where the reference is 200 ms using a real NES connected to a CRT. So that's less than 40ms of input lag.

Don't shooting fanatics love the XRGB? And doesn't it add 2 frames of lag on top of whatever your display (minus deinterlacing) has? I just can't imagine that a few ms of lag could possibly be an issue. All the shooting game and fighting fanatics don't seem to mind.

It is a frame shift issue. There are a certain number of frames available to respond. Every frame of latency reduces that window and potentially impacts the outcome. If the total available frames is large enough you can react fast enough to make up for the lag. But there are definitely games where the total available frames are small enough that most people can't respond fast enough and the latency shifts their reaction time outside of the alotted time by game designers. 

It depends on the game how large an issue it becomes, but two frames can definitely shift you into the kill zone for your response to game cues.

Eh, it's not an issue that's currently relevant to me. My comments were in response to this post of yours: I guess I'm wondering what "other systems" you think are so well emulated, other than ZSNES (which had notorious bugs and compatibility problems for ages). From your posts, it sounds like your criteria for good emulation have more to do with screen tearing than accuracy, no?
Interesting, and I tracked down a link. That said, I'd want to have a tool that measured it the other way around; comparing user times on CRT vs. LCD, etc. is useful, but not as empirical as directly measuring the time between hitting a button and getting an audio/video response.

I don't care if the game runs 1 frame off or something. For me, screen tearing and input lag are much bigger issues. I can go into ZSNES, run it in full screen mode with no tearing and no discernable lag.

I think maybe ZSNES and SNES9x both used frameskip to achieve these results. But sometimes frameskip is horribly noticeable (like in Nestopia) and sometimes it isn't (like in ZSNES)... I don't get it.

It might be enlightening to read these:

http://arstechnica.com/gaming/201...

https://web.archive.org/web/20120...

The issues in accurate emulation go way beyond "one frame off". Speedy Gonzales couldn't be beaten on the ten-year-old version of ZSNES you mentioned!

Also, I want to renew my earlier question -- what other platforms do you think are better emulated than the NES?

I think special code was written for the 50 most popular games or something. I don't really care if there are compatibility issues with very obscure games. I only own the most popular games anyway, so that's all I'm interested in playing.

It shouldn't be that hard in this day and age to play in full screen, with no screen tearing, minimal input lag, and no audio crackling. I think I was able to achieve that with even playstation emulators recently.

We're getting into the one frame bs again aren't we? Buy http://www.leobodnar.com/shop/ind... and stop wondering. Then turn around and sell the tester on ebay, or keep it for when you shop for your next tv. Then you know if you should blame your TV or something else.

Edit: And SNES is horriable for emulation, it's a complex beast.  NES isn't as simple as people think too thanks to half a billion mappers all over the place. If you want accurate emulation the MESS project would be where you want, not stand alone emulators.

It's not BS.

Latency doesn't need to exceed your response time to be a factor.
It doesn't even need to be a large percentage of your reaction time.
Nor does it need to be visibly obvious to you as an observer.


It just needs to reduce the available response window to something smaller than your response time to make certain in game actions impossible (such as low-reaction-time precision in-game cues).  

That can be as small as a frame, or two.



1 frame at 60Hz is 17ms, which is on the order of 10% of a reaction a little faster than average.
2 frames is 33ms, which is around 20% of a "fast" reaction.

Some game events don't give you that kind of leeway.


If your reaction time is already fast at 170 ms (versus an average of 220ms, or so), and game designers only give you 200 ms to complete an event (so average players can't do it in the first place), then you get two frames of latency, suddenly only 167 ms is available and even with a 170ms reaction time you're dead.


I fail to see how this very basic arithmetic is "BS".

Also, don't confuse my stance that it matters sometimes as it being a factor ALL the time.
The situations with that tight of a reaction tolerance are few and far between, but it is silly to claim they don't exist.





And this is different than the argument of a game feeling sluggish and unresponsive, in general, which requires considerably more latency, though less than you seemed to imply in the other thread.

Visual systems in professional simulation, for instance, cannot exceed 150ms of latency to be certified, but I can tell you from experience that immersive visuals become uncomfortable to look at with 100ms latency and possibly less.  Nobody in that industry would sell a system that approached 150ms because nobody would buy it, because pilots would be puking due to the motion/visual mismatch, along with the mismatch in control command and aircraft response.

Just so we're 100% clear on what I'm saying since you missed the first long drawn out topic I guess, my whole arguement is people over estimate how 1 frame in video games work. I'm not saying lag isn't realy or any of that jazz. I'm saying 1 frame doesn't work like most people think.

1 frame is the same time the second duck in duck hunt is a white block.  When you play duckhunt, try to see which duck flashed first, then ask the person next to you which one flashed first, see how often you agree. In Tetris on nes, the blocks to not move every frame until level 29.  That's how small of a window a frame is.  Not all games will REACT to your button presses within a single frame.

Fighters are normally quoted for lag issues. A quick jab in tekken is 8 frames.  So people assume with one frame of lag, it will be 9 seconds.  But you've actually buffered your input before the first frame of the animation can run in most cases, so it still comes out exactly the same.

Because a frame is 16 2/3ms, all games have a random amount of lag up to 16 2/3s for every single button press, because you're not controlling if it's at the leading or trailing edge of the frame.  And that's only if they poll input every frame.  People assume because a game is displaying 60 FPS, everything in it is moving at 60 FPS.  Tetris is a great example of that, you can not move the blocks left or right at 60 fps, nor do they drop at that speed till levels 29+

And any game that only gives you 200 MS to REACT to something is crazy.  Twitch shooters give more than that even. To cross a 320 pixel wide screen in 200 ms, the sprite has to move 26 pixels a frame. That's some very choppy animation that would need some sort of blending to even look right.

I am well aware of how small of a window 1 frame is at 60Hz, and I am fairly certain I know at least as much, if not more, about the underlying mechanics of Tetris than you do.


The 200ms I quoted isn't really the important part of the concept.
Pick ANY number.  If the available reaction time, less the latency, is smaller than your own reaction time, it means you fail at that in-game event.
It is not unthinkable that 1 or 2 frames can represent that threshold if you are already close to the margin, or the game provides only a small available margin to begin with.

Also, keep in mind that the up-to-1-frame of latency due to controller polling is in addition to any other latency, not concurrent with that latency.


And it has nothing to do with smooth or choppy animation.
Think the camera flash in the crowd on Punch Out, or Mike Tyson winking.
Or in Tetris, the appearance of the "Next" block and the number of frames you have to charge up the DAS accumulator.
It could even be just the beginning of a more complex animation.


And I think you are thinking down the wrong track with expecting the entire in-game event to happen within the times described.
It is just a matter of how much you can shift your response to an action and still eventually meet with success, not that the entire event, all animations included, occurs within the time described.

Ozzy -- let's try to meet in the middle on this.

I readily concede that 1 or 2 frames of non-design latency don't matter MOST of the time.
(and certainly wouldn't "feel" sluggish under most circumstances)

But I don't see why you find it unfathomable that there are conditions where your reaction time is already pushed to the limit to succeed at an in-game event, and that 1 or 2 frames can reduce the available time sufficiently to make you fail that in-game event.

Your apparent stance that it NEVER matters is what I disagree with, if nothing else due to the basic arithmetic.

That is what io system they used (opengl, directx, etc) not the accuracy of the console emulation.  Even your OS version could make a difference.  I assume your computer isn't painfully slow to begin with    Should figure out what the working ones use and see if there are NES ones that do the same.  

Its never just 1 frame, especially with PC emulators.  More than that can come from the controller alone.  Unfortunately that cool device only measures the digital input which won't be useful for an analog NES.

Unless it has been mostly rewritten since these tests, MESS is no where near the accurate stand alone NES emulators: http://tasvideos.org/EmulatorReso...

Since it takes about 400 ms for your brain to send a signal from your eyes to your feet (Hence Pro Trees in racing), and 200ish to hands, can you name one game event that happens at a completely random time with no warning, with that small of a window?  It's unthinkable.  It takes longer than 16 ms to press a button in most cases.

Yes, 1-2 frames of lag will make a tiny bit of diffrence.  So would shorter throw buttons and joysticks.  Or using extension cables on controllers. 

And just by downloading a 30 FPS video

 I counted tyson's wink at 5 frames.  This was the same number at both left and right eyes, so tyson's blink is somewhere around 8-10 frames in animation length on 60 FPS.  Camera flashes showed 1-2 frames per each step of animation, most of the second stages showed for 2 frames, so at 60 FPS that would be at least 3 frames, but most likely 5-6.  

So you're saying lag of 1/5th to 1/10th of Tysons blink will make some events in games unbeatable?

On average it takes 200ms (and as low as 120ms) for the human reaction time , not 400ms.

You can do an experiment at home with a ruler and some math to determine your average response time, if you'd like.

The one is going back to another topic.  People are under the impression 1 frame of lag makes a diffrence, but one frame at 60 fps is far smaller than most people can grasp. 

And I guess MESS wouldn't really be a good emulator for perfect emulation since they break more stuff than they fix every release.  The GOAL is perfect emulation, but theres so many cooks in that pot.  And on pot.

The 400 ms I mentioned is from eyes to brain to your FOOT, not hands.  That's the basis of the staging trees in drag racing.  So you would have to catch it with your toes.

Yes, that is what I am saying, that for some people, whose reaction is already on the margin of success, they will be tipped in favor of failing the in-game event.


It is basic arithmetic.

If (your reaction time) > (design reaction time - non-design latency) you will fail.  End of story.

The specific numbers are irrelevant to that point.




1 frame is obviously less likely to be the decider than 2 frames, and as Brian points out, it is almost certainly NOT "only" 1 frame of latency under any of the real-world circumstances of emulator + LCD.

I think you are a smart guy, so don't screw up your comments with obviously wrong stuff like this!

From the studies I've read, reaction time for feet is maybe 10ms slower than hands. It also depends on the application (are you comparing moving toes with fingers, or how quickly a person can lift their foot? For games that require both hand and foot movement, it all depends which reaction time will be faster. In this case, we're talking about pushing a button with your fingers, not your toes.

Hey man, 5 ns/m can really add up if you caccoon yourself in a series of controller extension cables!

I would totally believe an extra 200ms required to get full pedal travel in a drag racer over doing a button-press action with your hand.


But he is making the mistake of just doubling the 200ms average time for hand-actions.

The distance to your foot is roughly double the distance to your hand, sure.
But the vast majority of that 200ms is NOT transport delay, it is recognition and processing time.

Only the transport delay doubles in a foot vs hand response time comparison.

What this sounds like to me is this same made up arguement:

If you sit farther away from the TV, it takes longer for the light to reach your eyes.  Sure you may have to be a few light-seconds away for it to be realevant, but since we prove that distance does matter, specifific numbers is no longer relevant.

That's just a technicality.  Again, all I'm saying based on that other long ass drawn out topic, 1-2 frames are not going to do much.  Not all games themselves react in that time span. 3+ yea sure it'll be noticable, but if you loose an event because of 1 frame of lag, you were just too slow and cut it too close.

Can you name a game where you have that close of a margin ?