Previous Thread
Next Thread
Print Thread
Page 1 of 5 1 2 3 4 5
Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
I sent this email just now, but if I knew there was an active Nestopia forum I would have just post here instead in the first place :duh:

Just to say it's not my intention to spam.


Anyway here it is:


>
When Vsync is enabled, it causes a slight but noticable lag in input reaction. This is only the case when vsync is active. I even did a "blind test" to make sure I wasn't just imagining things :p

Also, the triple buffering option doesn't seem to work (screen tearing still occur).

Some people mentionned that vsync might be inferior to triple buffering in that it does have a tendency to cause input lag. I don't know if this information is accurate but this is what I heard. So I thought maybe this input lag problem could be solved if tb worked in Nestopia.

Here's a dicussion about it on the Zsnes forum:

http://board.zsnes.com/phpBB2/viewtopic.php?t=4926&postdays=0&postorder=asc&start=150




Thanks for your time and thanks for this amazing emulator

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
What we need is a test ROM or emulator code that somehow measures all three latencies: input, video, and audio. This would put an end to the "it feels laggy" kinds of reports, which are difficult to verify because they are on the threshold of perception.

I'm thinking of something along the lines of a regular visual/aural beat along with one controlled by a button on the joypad, where the player synchronizes with the regular beat. Subconsciously we will measure and adjust to any latency in order to get the beats in synchronous (basic feedback loop), which the emulator/test ROM could then measure. This would still only give you input+video and input+audio latencies, so I'm not sure how input could be separated.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Like I mentionned on the other board,I think it would be awesome to have an objective way (meaning: not done by a person) to measure those things. Like you said, it would certainly put an end to subjective reports.

However,I do think that the "blind test" I did was very good.(copy-pasting what I wrote)

Quote:
Btw Blackmyst, I did a self-administered blind test laugh

I got into the timing configuration screen where Vsync is and - without looking at the screen of course, repeatedly clicked the mouse on the Vsync option and then exit, in such a way that I didn't know if Vsync was on or off when I did exited. I even alternated my click "rhythm" so that I wouldn't always do an even or odd numbers of "clicks". And I tested this in parts of a game (Zelda 2) without scrolling, so there wasn't any screen tearing when Vsync was off (that would have been of course a dead giveaway)
..The actual "test" consisted of simply pressing down and notice how responsive "Link" was to duck.

Aaaaaanyway...I tested this more then twenty times, and guessed right 100% of the time...So I'm convinced this is not a sort of "auto-sugestive placebo idea" mumbo jumbo thing...

Again, to anyone saying they don't notice a lag: This lag is no more than a frame (1/60) or two max.
That's a lot of words for: "I think that test was pretty objective" but an extermal mean would be even better of course.

The test rom is not a bad idea, but for it to be of any use,I think it would need a "control" environment. For example, you do the test with Vsync on and then you do the same test with vsync off.

But if you just do it with nothing to compare to, it would not be very useful. People would just adjust their timing until they get it "right" and that would destroy the whole test. Plus you'd have to control for different hardware setups, and basically the same subjective human bia would be present.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
I just got an idea to measure input lag, but it would require an external program/module in conjunction with the emu.

The external program/module/dll would record the exact time which an input is pressed. It would also record the exact time in which a display change occur (for example Mario jumping or Link ducking)

And then compare the time at which the two event occured. Of course, the same rom and the same location in the game would have to be used each time.

If someone could manage to code such a small utility it would be quite awesome...

Joined: Jan 2006
Posts: 40
J
Junior Member
Offline
Junior Member
J
Joined: Jan 2006
Posts: 40
Windows, Linux, and OSX are not hard real-time operating systems. Hence there is certainly going to be latency, and there is no bound on that latency. So any tests would just show that for that system, such and such latency was observed. Many aspects of a computer can affect the latency measured.

USB alone has a latency due to the polling rate of HID devices, which is typically 8ms. So that is the minimum latency from you pressing a button on a controller to your OS's device driver reading the data. Then there is the latency of your OS getting that data to the emulator. Roll in the factor of process scheduling, which again, is not hard real-time, and also factor in the synchronization between the display device and the current state of the emulator (say the current logical NES cycle it is executing)... and you will end up with a very large range of possible end-to-end latency.

A real NES, of course, has none of these issues. I don't want to discourage anybody, as there are many people here smarter and more creative than me. But I'd say that the issue of latency in input, video, and audio is going to be the most difficult thing to perfect with regards to emulation accuracy. Much of the problem is out of the realm of the emulator, i.e., hardware and OS limitations may prevent perfect timing accuracy.

It would be great if the entire PC system (CPU, video, audio, and HID) could be forced into lockstep synchronization so as to match up exactly with a NES, but is that even possible with common PC hardware?

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
All valid points.

But what I was saying is that there is definitely more latency when vsync is enabled. That's something that's probably within the control of the program. I'm still curious to see if the problem would persist if triple buffering worked. Like I said, I read it doesn't cause as much lag as vsync.


To be honest, I personally can't perceive any lag when vsync is off, even though there has to be some for the reasons you gave above. If only a few ms...

I still think the idea of an external program/module to measure (to the best capacity of the PC at least) would be very useful in many situations, such if you want to compare the response time of different Nes emus or if there is any difference between response when vsync/triplebuffering is on/off etc...

Such a method could never take into account the lag caused by the usb gamepad and similar factors but it would be a good start.

Joined: Jan 2006
Posts: 40
J
Junior Member
Offline
Junior Member
J
Joined: Jan 2006
Posts: 40
Quote:
Originally posted by Redx:
I just got an idea to measure input lag, but it [b]would require an external program/module in conjunction with the emu.

The external program/module/dll would record the exact time which an input is pressed. It would also record the exact time in which a display change occur (for example Mario jumping or Link ducking)

And then compare the time at which the two event occured. Of course, the same rom and the same location in the game would have to be used each time.

If someone could manage to code such a small utility it would be quite awesome... [/b]
I don't think that the measuring device can run on the PC itself, because the latency is the time interval from a physical human pressing a real world button, all the way to the audio and video changing due to the button press. Even on a real NES, there will be some delay. The goal should be to have the delay be as close as possible to the delay on a real NES.

Maybe somebody that is good with electronics can string together something that can plug into the video, audio, and USB ports of a PC? But even that wouldn't account for possible latency introduced by the actual devices hooked into those ports. How small is the delay from a video signal entering a CRT to the time the signal is converted into photons? Similarly what is the time delay for pressing a button on a gamepad and that gamepad turning the button press into a USB packet?

It seems as though only blargg's method will measure the entire system for latency.

Joined: Jan 2006
Posts: 40
J
Junior Member
Offline
Junior Member
J
Joined: Jan 2006
Posts: 40
What is your display devices refresh rate? What is the polling rate for your USB gamepad? There is a Windows USB driver hack that lets you increase the polling rate from 125hz to 1000hz. Have you tried that, as well as increasing the refresh rate for your display device? The maximum delay due to vsync is bounded by the refresh rate of your display device.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Quote:
What is your display devices refresh rate?
Right now it's 100hz. But when I'm using Nestopia: 60hz. Anything else just isn't as smooth...and yes, that includes multiples (i.e: 100hz for Pal 120hz for Ntsc)

Quote:
as well as increasing the refresh rate for your display device? The maximum delay due to vsync is bounded by the refresh rate of your display device.
I do believe using 120hz WOULD fix the issue. But like I said, 120hz just isn't as smooth as matching the original refresh rate..So it wouldn't be a perfect solution. I'd rather just turn off vsync.


Quote:
There is a Windows USB driver hack that lets you increase the polling rate from 125hz to 1000hz
Whow didn't know... Will check it out

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Quote:
But I'd say that the issue of latency in input, video, and audio is going to be the most difficult thing to perfect with regards to emulation accuracy. Much of the problem is out of the realm of the emulator, i.e., hardware and OS limitations may prevent perfect timing accuracy.
Agreed, unfortunately. I see no way around the latency issue on a modern PC. It's only getting worse, as each new software layer adds latency. They can keep increasing throughput, but latency is not something that more horsepower can improve much. Maybe the ultimate emulator will eventually be a mini-PC-on-a-card with its own CPU, joypad input and video output.

Finally, an advantage to running an ancient operating system (Mac OS Classic in my case) that lacks pre-emptive processes and allows a process to hog the CPU! Hmmm, maybe real-time/customized versions of Linux might be best for emulation.

Quote:
I don't think that the measuring device can run on the PC itself, because the latency is the time interval from a physical human pressing a real world button, all the way to the audio and video changing due to the button press.
Exactly. To measure it really accurately you'd need something like a high-speed camera.

I think my original idea might not work, but here's one that would definitely work: a reflex tester. NES ROM changes the image/makes a sound and you press the button when you notice it. Run test multiple times to get an accurate result that is the sum of your reaction time and the latency. Run test with various emulator configurations and you can find the relative latencies. Run test on your NES and you can compare the real thing with the emulator. Hard data. I'll have to get on this tomorrow.

As for vsync, it would be best for the emulator to wait for vsync before polling input and emulating the frame. If it does these latter things first, the time between that and vsync results in added latency. If it's up to the emulator to choose when to refresh under Windows, the the emulator can take things one step further and wait until the monitor beam hits the top of the window rather than the usual top of the entire screen. It would of course have to assume the usual top-to-bottom scanning pattern. I've implemented this kind of beam-position calculation on my Mac and it works. It requires that you have an accurate timestamp as to when the host monitor's vsync occurs.

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
I whipped up a quick reflex tester ROM which I hope to clean up another time. When run, it makes the screen white and waits for your to press A to seed the random number generator. It clicks and delays for 2-6 seconds, then clicks and makes the screen white. At this point you should press A as quickly as you can. It prints the number of milliseconds between the screen changing and you pressing A, then waits for you to press A to start another trial.

Take several times and average them for better accuracy, since the figure varies by many tens of milliseconds. On an emulator that only reads input once per frame, measurements will always vary by a multiple of 16.6666.

I took measurements for several setups involving my NES and an emulator on my PC with a CRT refreshing at 76 Hz. For each setup, I took 12 times and found the average. For audio, I used headphones.

Code:
189	Video, NES on TV
194	Video, NES on video capture
227	Video, emulator using custom serial joypad
236	Video, emulator using keyboard
254	Video, emulator using keyboard, vsync enabled
231	Video, emulator using custom serial joypad, vsync enabled
191	Audio, NES RCA out
254	Audio, emulator using custom serial joypad
Take your own measurements and post them with a description of what you timed.

reflex_timer.nes

Joined: Mar 2002
Posts: 1,255
Likes: 43
H
hap Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: Mar 2002
Posts: 1,255
Likes: 43
Redx: The technique of triple buffering will only work in fullscreen, have you tried that ?

Also, setting your refresh rate to 120hz or 60hz (or 50/100 for PAL), won't make accurate NES emulators run smoothly, as the (NTSC) NES refresh rate is not exactly 60hz. To demonstrate this, try setting vsync off, and you'll see an ugly 'line' slowly moving downward.

Joined: Mar 2002
Posts: 1,255
Likes: 43
H
hap Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: Mar 2002
Posts: 1,255
Likes: 43
Using an emulator (Sega Li), TFT screen at 75hz, headphones for audio, DirectX input.

Using keyboard, USB joypad, or wireless USB mouse made no difference. Enabling or disabling vsync didn't seem to cause a difference either.

video: between 197 and 213
audio: usually 230 (probably due to latency)

Strangely (assuming the mouse would be the slowest), my 'high score' was obtained with the mouse (181).

*edit* Using Nestopia, I get the same results, didn't test audio though.

Joined: Jan 2006
Posts: 138
M
Senior Member
Offline
Senior Member
M
Joined: Jan 2006
Posts: 138
Does your problem account for *all* different input devices, i.e keyboard, joysticks? Are there any lags when you run Nestopia in desktop mode with the default refresh rate set to 60hz in the control panel?

Your joystick, if that's what you're using, what's the name of it? Is it USB or gameport driven?

What gfx card and driver are you using? Is it MS certified? Certain driver vendors likes to stack up internal screen buffers in order to get higher scores on 3D benchmarking programs. Have you made sure you don't use any bogus gfx driver settings and that its own 'Triple Buffering' option is disabled?

Here's a test you can do. Run and compare the input response on SMB1 and VS.SMB1. On non VS games it takes place the instant the emulated game requests it and slight earlier on VS games.

Quote:

Also, the triple buffering option doesn't seem to work (screen tearing still occur).
That's not the main goal of triple buffering. It's there to help, but not on synchronizing.

Quote:

Some people mentionned that vsync might be inferior to triple buffering in that it does have a tendency to cause input lag. I don't know if this information is accurate but this is what I heard.
Not really. From a gamer's perspective it can be seen that way, but they're conceptually different. I generally don't recommend triple-buffering in emulators unless there's actually a speed problem or if the user is happy with the delay it imposes. Further more, extra back-buffers are managed by Direct3D so there's little a developer need to do to support triple buffering.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Blargg, that's pretty neat.

Although it can be a valuable tool in many instances it's main problem is that it relies on human reaction,which is relatively slow and not totally constant.

The idea I proposed, while not perfect, has the advantage on not relying at all on human reaction,(or for that matter, any kind of human interaction if you manage to code an automated test that just pass the input to the emulator)
.The program simply compare the time the input is entered and the time the display is updated, so there's no any kind of "You must press........ NOW!' involved.


Quote:
Does your problem account for *all* different input devices, i.e keyboard, joysticks? Are there any lags when you run Nestopia in desktop mode with the default refresh rate set to 60hz in the control panel?

Your joystick, if that's what you're using, what's the name of it? Is it USB or gameport driven?

What gfx card and driver are you using? Is it MS certified? Certain driver vendors likes to stack up internal screen buffers in order to get higher scores on 3D benchmarking programs. Have you made sure you don't use any bogus gfx driver settings and that its own 'Triple Buffering' option is disabled?
I'll do a test and report back.

Joined: Jan 2006
Posts: 138
M
Senior Member
Offline
Senior Member
M
Joined: Jan 2006
Posts: 138
Very nifty utility. Here's what I got using my GameCube controller via a special USB adapter:

197+197+197+197+181+197+213+181+197+197+197+213 / 12 = 197.00 <- 60hz, no vsync
197+213+181+197+213+197+181+181+181+213+197+197 / 12 = 195.67 <- 120hz, no vsync
213+213+213+213+213+197+197+197+197+213+197+197 / 12 = 205.00 <- 60hz, vsync
213+197+181+197+197+197+213+230+181+213+213+213 / 12 = 203.75 <- 120hz, vsync

As Jack Burton says, it's all in the reflexes.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Quote:
Very nifty utility. Here's what I got using my GameCube controller via a special USB adapter:

197+197+197+197+181+197+213+181+197+197+197+213 / 12 = 197.00 <- 60hz, no vsync
197+213+181+197+213+197+181+181+181+213+197+197 / 12 = 195.67 <- 120hz, no vsync
213+213+213+213+213+197+197+197+197+213+197+197 / 12 = 205.00 <- 60hz, vsync
213+197+181+197+197+197+213+230+181+213+213+213 / 12 = 203.75 <- 120hz, vsync
I think it's safe to say that the results are inconclusive at best...Even if it does sugest there's slighly more lag with Vsync on...But I think it cannot be use to do objective testing.

Is there any way to avoid the screen tearing without enabling vsync? I'm curious what is the exact fps of the Nes?


Btw I have a Saitek P880 but I fail to see how it could be the gamepad's fault seeing as it does work perfectly without vsync..I realise there may be more to it but...

Also I turned off the horizontal/vertical syncronization in my card's driver (Diamont S85 128MB DDR Radeon 9250 series AGP (0x5960) ) and the lag is still present (I always do a blind test to determine it and I guess right everytime)

I can do more test such as running in a window or running fullscreen at 120hz


Quote:
Redx: The technique of triple buffering will only work in fullscreen, have you tried that ?
Yes, stil gets tearing.

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
A couple of timing notes: The measurement of reaction time includes all of the following: time it takes you to respond, input latency, process scheduling overhead, processor time used for emulation, time used to send graphics to video card, (optional) time while waiting for vsync, time for the monitor to display the image (beam retrace or equivalent on LCD). For audio, replace the video with outputting sound to audio buffer, when the buffer is acually read (similar to monitor retrace), and the time it takes for the sound to travel from the speakers to your ears (not sure what this is, might only be a few milliseconds).

Each person's measurement will be different, if only for their differences in reaction me. Assuming this has stable characteristics, this allows relative comparison between one person's measurements, but not comparison between different people's measurements. If two people measured on the exact same system, then differences in reaction time could be determined. The best system for doing this is the NES, due to the lack of variability in setup (except if you're using a modern new-fangled HDTV or some crap like that, yes, they will be crap for a NES).

I think we need someone with some fluency in basic statistics here. I'm thinking that it would help in analyzing the vairiances in values and drawing useful conclusions.

Quote:
Redx: Although it can be a valuable tool in many instances it's main problem is that it relies on human reaction,which is relatively slow and not totally constant.
I just want to say that you're style of discussion is very annoying. Almost every post has a "yes but". How about exploring the topic rather than turning it into a ****ing debate? As in, "how can we eliminate the error caused by varying raction times?" the answer to which is: run many trials on the assumption that variances in one's reaction time will be uncorrelated with the time we're trying to measure. You're not the only one guilty of this, but it's really irritating to interact with. Start with the assumption that problems can be solved and that people are going to explore the issue rather than stick entirely to the original problem statement as you posed it and constantly rebut.

Quote:
Redx: The idea I proposed, while not perfect, has the advantage on not relying at all on human reaction,(or for that matter, any kind of human interaction if you manage to code an automated test that just pass the input to the emulator)
.The program simply compare the time the input is entered and the time the display is updated, so there's no any kind of "You must press........ NOW!' involved.
This requires that the PC know when the image reaches the monitor. Or when the sound reaches the speaker cone. It doesn't.

Quote:
Redx: Even if it does sugest there's slighly more lag with Vsync on...But I think it cannot be use to do objective testing.
And it continues.. but but but. Take the humble approach and assume that you might be wrong. So say "How can this tool be be used to make objective measurements?" Good question. Let's discuss it and elaborate on things anyone doesn't understand.

Joined: May 2003
Posts: 225
T
Senior Member
Offline
Senior Member
T
Joined: May 2003
Posts: 225
Quote:
Btw I have a Saitek P880 but I fail to see how it could be the gamepad's fault seeing as it does work perfectly without vsync..I realise there may be more to it but...

Also I turned off the horizontal/vertical syncronization in my card's driver (Diamont S85 128MB DDR Radeon 9250 series AGP (0x5960) ) and the lag is still present (I always do a blind test to determine it and I guess right everytime)
I'm also the owner of Saitek P880's (x2). Never experienced lag with Vsync on or off. There are updated drivers for the P880 available at Saitek website - Make sure you have the latest drivers.

Additionally, I own a Radeon 9800 PRO. No screen tearing with Vsync On. Triple Buffering has no impact for me whether I turn it on or off. I use Catalyst 4.12 drivers, as they work best for my card and setup.

-Trebor

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Blargg, sorry if you find my posting style annoying, believe me, I don't want to argue for the sake of arguing.


Quote:
This requires that the PC know when the image reaches the monitor. Or when the sound reaches the speaker cone. It doesn't.
I admit that I may have misunderstood the problem...

I realise the PC cannot know when the image on the monitor is updated. But the way I thought about it is that you could have an utility that knows the exact time video data has changed. The same way Fraps can capture directX video data without ever needing a monitor whatsoever...

But then, that wouldn't necessarily take into account many factors causing the perceive lag,and the results wouldn't mean anything anyway...well I'm not sure.

Joined: Jan 2006
Posts: 138
M
Senior Member
Offline
Senior Member
M
Joined: Jan 2006
Posts: 138
Quote:
I think it's safe to say that the results are inconclusive at best...Even if it does sugest there's slighly more lag with Vsync on...But I think it cannot be use to do objective testing.
Can't you at least *try* it and report back what you got? You could test it on other NES emulators and see if it's a Nestopia-only thing or if others give you similiar lag. I'd really like to fix this (provided this is in fact a bug in Nestopia) but you gotta give me something to work with. I asked those questions because they're relevant to the issue and they'll help me a great deal by letting me concentrate on certain parts in the source code that may affect this behaviour.
Quote:

I'm curious what is the exact fps of the Nes?
NTSC: 21477272.72 / ((262*341*2-1)*2) = ~60.0988 fps
PAL: 26601712.5 / (312*341*5) = ~50.007 fps

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Quote:
NTSC: 21477272.72 / ((262*341*2-1)*2) = ~60.0988 fps
Thus, a NES emulator which ran at 60 frames per second in order to synchronize with the monitor's refresh would be off by a factor of only 0.0016.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Jagasian, I searched for the USB polling rate driver hack you mentionned but the only info I found on it concerns USB mouse polling rates...

Quote:
Can't you at least *try* it and report back what you got? You could test it on other NES emulators and see if it's a Nestopia-only thing or if others give you similiar lag
Ok I did some test and here are the results:

Nestopia Fullscreen VsyncON 60hz - = 243
246,246,246,213,246,213,246,279,246,279,213,246

Nestopia Fullscreen VsyncOFF 60hz - = 197
197,213,197,181,197,181,181,213,197,197,197,213

I also tested with VirtuaNes 092e (60hz with both vsync on and off) the average was about 213. I also did my own blind test and haven't notice any difference with vsync on or off.

Joined: May 2003
Posts: 225
T
Senior Member
Offline
Senior Member
T
Joined: May 2003
Posts: 225
Here are my results using my Saitek P880 with Nestopia 1.28:

Full Screen 60hz with VSync Off= 213.33
197,230,230,197,230,197,213,213,230,197,213,213

Full Screen 60hz with VSync On= 217.33
197,213,213,213,230,213,230,213,230,230,213,213

Like I said before, I never experience any lag.

-Trebor

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
I just tested with the latest MESS and found no lag whatsoever with or without triple buffering. I did the usual blindtest.

Incidently vsync doesn't prevent screen tearing in MESS while TB does..Exact opposite of Nestopia.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Ok don't flamme me or anything but I just got another idea...and this one doesn't suck (I think).

If Blargg doesn't mind coding another test rom (this will probably be even more simple than his reflex_test rom)

The basic idea would be to program a rom that simply make a noise at the exact same time it change the display.
So basically you start the test by pressing A, one second later the screen turns white and at the exact same time you hear a noise.


This is resting on the assumption that,while the display may be lagging, the audio will not (or not as much at least)

So the person can evaluate if there is lag between audio and video (if any) in various setups,emulators,hardware etc...Like a desync avi movie or something.


So how does this sound? (btw I realise there's allready a poping noise with the current reflexetest rom, but I don't think it has been programmed with the intention of comparing video and audio in mind, the pop clearly comes afterward)

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Quote:
The basic idea would be to program a rom that simply make a noise at the exact same time it change the display.
Nifty idea. This of course relies on the user to do the timing, but it might provide further useful data. The current test should allow this somewhat, since it makes a click at the same moment it changes the screen.

Hmmm, I could write one which only relied on the user to adjust the timing until the image and sound occurred at the same time. You could use left and right to adjust the relative timing until you perceived them to be in synchronous, then press a button to get the relative delay the test is having to introduce. Run this test with two different configurations and compare the two values to find the relative difference in latency.

That gives me another idea for the original test. It could display a steady tempo of flashing/sound and have you press the button at the same regular rhythm. Presumably this would remove reaction time, since you could anticipate the regular rhythm. You'd unconsciously adjust your timing so that you were pressing it just as the image appeared (unless you absolutely suck at music and rhythm, in which case it's time to hit Parappa for some practice first).

I guess I'll have to do some writeups on these tests eventually, to help people write them for other platforms, since they're so useful for measuring responsiveness.

Quote:
(btw I realise there's allready a poping noise with the current reflexetest rom, but I don't think it has been programmed with the intention of comparing video and audio in mind, the pop clearly comes afterward)
Heh, it actually occurs a few milliseconds before the image changes (at least on a NES). This thread is bringing to light some interesting physiological facts (like the average 200 msec reaction time).

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Thanks for the idea, Redx; the new tests are great and much more accurate (well, assuming I've written them correctly).

Time_Latency.nes times overall latency from joypad input to audio output. When run, it clicks at a regular interval and your task is to press a button in sync with the sound (any button on the joypad will work). After you establish a good rhythm and maintain if for the last four presses, you can stop pressing the button and read the result on screen, which is the average of the last four presses. It's best to close your eyes to avoid visual distraction (especially trying to read the time on screen, which could influence you adjust your timing to get a particular value). I noticed that I normally pressed the button early, so I had to consciously delay a bit until the sound of the button pressing was in synchronous with the click. When that occurred, there was a clear audible difference in my head that I was in sync; it was as if the click and my button press became one (experiment and you'll hear what I mean).

Audio_Latency.nes times the relative latency of audio as compared to video. When run, it clicks and flashes a box at a regular interval. Use the joypad to adjust the delay until the sound and image seem synchronized. Up and down make coarse adjustments, and left and right make fine adjustments. Hold the direction to adjust the delay value shown, as it changes fairly slowly. Adjust the value past what seems correct, so you get a feel for how much of a difference there is between synchronized and unsynchronized.

Both tests display the value in milliseconds relative to a NES. Time_Latency gives an emulator's input+audio latency, and the difference of Time_Latency - Audio_Latency gives the emulator's input+video latency.

On my NES emulator with vsync disabled on a 76 Hz CRT monitor, Time_Latency gave 58 msec and Audio_Latency gave 20 msec. This means that joypad input to audio output latency is 58 msec greater than a NES, and joypad input to video output latency is 58 - 20 = 38 msec greater than a NES. For reference, a video frame is 16.7 msec long.

NESASM-format assembly source code available on request.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Quote:
but it might provide further useful data. The current test should allow this somewhat, since it makes a click at the same moment it changes the screen.
Now I'm not a Nes/Famicom guru but currently the small "p-pop" sound like some kind of audio device being initialized. Maybe the sound should be longer. (For example, the first triangle note of the third world music in SMB3)

Also I see no reason to fill in the whole screen. Just a small portion should be enough.Probably preferable for this kind of test imo. The reason for this is I get the impression the whole screen "filled up" progressively (barely noticable though). The smaller the portion of the screen, the more "instantaneous" it appear. And it's just less distracting to focus on a small visual area. Anyway, not really important I guess.


Quote:
Hmmm, I could write one which only relied on the user to adjust the timing until the image and sound occurred at the same time. You could use left and right to adjust the relative timing until you perceived them to be in synchronous, then press a button to get the relative delay the test is having to introduce. Run this test with two different configurations and compare the two values to find the relative difference in latency.
Could be useful, as long as there is an option to have them come up at the exact same time (independently of any user perceptions)

Quote:
That gives me another idea for the original test. It could display a steady tempo of flashing/sound and have you press the button at the same regular rhythm. Presumably this would remove reaction time, since you could anticipate the regular rhythm. You'd unconsciously adjust your timing so that you were pressing it just as the image appeared (unless you absolutely suck at music and rhythm, in which case it's time to hit Parappa for some practice first).
Excellent idea. Imo I can see this could give more consistent result (overall) than the reflex test (the reflex test can still be useful in some cases of course).


Quote:
I guess I'll have to do some writeups on these tests eventually, to help people write them for other platforms, since they're so useful for measuring responsiveness.

Quote:
(btw I realise there's allready a poping noise with the current reflexetest rom, but I don't think it has been programmed with the intention of comparing video and audio in mind, the pop clearly comes afterward)
Heh, it actually occurs a few milliseconds before the image changes (at least on a NES). This thread is bringing to light some interesting physiological facts (like the average 200 msec reaction time).

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Oh shoot, you posted the test while I was replying! Oh well :p I'll check the new test now.

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Quote:
Excellent idea. Imo I can see this could give more consistent result (overall) than the reflex test (the reflex test can still be useful in some cases of course).
Wait a minute... what am I saying here??? Both test are completely different in nature. Since Time_Latency.nes only relies on audio and input, it won't be affected by anything that could cause video lag.

Anyway,both tests are great. In audio_latency, I adjusted the timing until I felt video and audio were synced and when I switched vsync, it did felt like they weren't quite as synced anymore.

Curious to hear about others impressions.

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Quote:
Anyway,both tests are great. In audio_latency, I adjusted the timing until I felt video and audio were synced and when I switched vsync, it did felt like they weren't quite as synced anymore. Curious to hear about others impressions.
What about the objective stuff? Touchy-feely stuff is only useful as a guide to finding the objective. Run audio_latency, note the value, then run time_latency and the difference is your video+input latency. What figures do you get with and without vsync? (and why the reluctance of posting your results?)

I'm attempting to improve audio_latency, since it's hard to visually tell how in-sync they are. I just tried one that had a block moving horizontally across the screen with a pointer you move left and right until it seems that the click occurs when the block crosses the pointer. I'll have to test this more tomorrow.

As you can see, I eliminated the full-screen flashing (it was too much, as you said). The only reason the original ones did that was due to them being quick hacks. I spend more time on these (should be obvious) and liked the flashing square much better. As for the sound, I figured a click would be the easiest sound to identify. I'll try other sounds too (maybe a high-pitch square wave).

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Quote:
What about the objective stuff? Touchy-feely stuff is only useful as a guide to finding the objective. Run audio_latency, note the value, then run time_latency and the difference is your video+input latency. What figures do you get with and without vsync? (and why the reluctance of posting your results?)
Not to start an argument but there's no truly "objective" results here.It can give you a general idea and some pointers,but no hard facts. Unless someone can come up with a genius software-only test, the truly objective results can probably only be achieve via external hardware,like a high speed camera or something like you mentionned. I don't think we've reach the limits of software only test though.

Anyway, now for my results:

All test are done in fullscreen 60hz. One time with 640x480 another time with the superior resolution for Nes emulation: 512x480. (no difference noted when using 640x480 as opposed to 512x480)

In audio_latency, I adjust it to +85 to feel both audio and video are synced. This is entirely subjective though and someone else,on the same computer, might feel they are synced when the adjustment is set to say -15... And like I said, if I change the vsync setting afterward (whether it's turning it on or off) it doesn't feel quite as sync anymore.

Now for the Time_latency: I don't look at the screen and concentrate on synchronizing my presses with the beat. I get a pretty constant +140/+155. Whether Vsync is on or off it doesn't seem to have any effects on my results. And unless I got something wrong, there's no reason to expect it should,since it shouldn't have any effects on audio or input lag, only video.


Quote:
I'm attempting to improve audio_latency, since it's hard to visually tell how in-sync they are. I just tried one that had a block moving horizontally across the screen with a pointer you move left and right until it seems that the click occurs when the block crosses the pointer. I'll have to test this more tomorrow.

As you can see, I eliminated the full-screen flashing (it was too much, as you said). The only reason the original ones did that was due to them being quick hacks. I spend more time on these (should be obvious) and liked the flashing square much better.As for the sound, I figured a click would be the easiest sound to identify. I'll try other sounds too (maybe a high-pitch square wave).

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Quote:
Not to start an argument but there's no truly "objective" results here. [...]
You sure are good at being annoying. You can be perfectly objective here by reporting hard results. "When I ran the test, I got xx msec as a result." That's objective, regardless of whether my test ROM is working or its value is meaningful; the objective part is your report of what value it printed on screen. For that matter, "chocolate tests good to me" is also an objective report (of a subjective experience). It's really confusing, since you on the one hand talk of being objective, but then avoid mentioning objective measurements about your system, and seem in general uninterested in solving the problem you brought up. I don't get it.

Quote:
In audio_latency, I adjust it to +85 to feel both audio and video are synced.
Is this with vsync enabled or disabled?!?

Quote:
Time_latency: [...] I get a pretty constant +140/+155. Whether Vsync is on or off it doesn't seem to have any effects on my results.
Vsync should have no effect on this test.

Based on these values, I calculate that the latency from joypad input to video display on your system is 63 milliseconds, and the latency from joypad input to audio output is 148 milliseconds. If you run two audio_latency tests, one with vsync and one without and post the results, we can compare the input->video latencies for both, the ultimate point of the tests.

I think I figured out the reason for your contradictory approach: you're attempting to exert control on the discussion and the conclusions we might draw, perhaps thinking that we will draw the wrong ones and not solve your problem. This would explain why you are reluctant to post any hard data which we might draw our own conclusions about. Here's my advice: try a different approach of assuming that we are quite competent here and will solve the problem without the need of interference with our investigation. Sorry if I seem harsh, I just won't keep silent about bull**** (cue RB's profanity filter).

Joined: Mar 2001
Posts: 16,919
Likes: 57
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,919
Likes: 57
Yeah, I've gotten the impression all thread that he was fishing for some specific "fix". Emulation doesn't work that way any more, we do things *right* :-)

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Quote:

You sure are good at being annoying.
Your impressions. We could also say you're annoyed too easily.

Quote:
You can be perfectly objective here by reporting hard results.
Difference in perceived meaning. "Hard results" when the results is not necessarily meaningful is not true "hard results" imo

Quote:
For that matter, "chocolate tests good to me" is also an objective report (of a subjective experience).
Ok ok. I don't want to argue semantics.

Quote:
It's really confusing, since you on the one hand talk of being objective, but then avoid mentioning objective measurements about your system,
I gave all the information I thought was useful. Now if there something I should have mentionned,just ask and I'll asnswer...

Quote:
and seem in general uninterested in solving the problem you brought up. I don't get it.
Completely untrue.


Quote:
Quote:
In audio_latency, I adjust it to +85 to feel both audio and video are synced.
Is this with vsync enabled or disabled?!?
Disabled. And then I enable it (vsync) and notice the difference... Chill, sheesh. I'm saying that +85 doesn't mean anything. It's just my impression. Someone else, with the same PC and Nestopia settings would probably give you some other numbers...


Quote:
Based on these values, I calculate that the latency from joypad input to video display on your system is 63 milliseconds,
"My system"... Ok, so..what does "my system" means exactly? Is it my actual PC hardware? Or the results with Nestopia? I mean we could have different definitions of "one's system".

Because like I said, I don't experience this in MESS... So this pretty much remove the possibility that this is hardware related on my end. Unless you're going to argue that my particular hardware/software setups doesn't cope well with the way Nestopia does vsync, but I'd found that extremely suprising...I'm not the only one that noticed the lag anyway with vsync enabled in Nestopia anyway.

Quote:
and the latency from joypad input to audio output is 148 milliseconds. If you run two audio_latency tests, one with vsync and one without and post the results, we can compare the input->video latencies for both, the ultimate point of the tests.


Most of these "numbers" don't mean anything meaningful. So any "conclusions" you could come up with don't mean anything 'either'.

Sorry, but I find these tests and conclusions similar to something like the "Torah code"...

No only the results varies for everyone,but most importantly 'the results varies every time someone perform the same test'. *You are getting random values(caused by the person and other factors..not the test itself)* in other words. Only the insane try to make sense of random values. And there's not any kind of averaging method you can use to make sense of them either. There.


Quote:
I think I figured out the reason for your contradictory approach: you're attempting to exert control on the discussion
Oh lord...Re-read your replies sometimes. I couldn't care less about "exercing control on the discussion". Jesus this is getting out of proportion...


Quote:
and the conclusions we might draw, perhaps thinking that we will draw the wrong ones and not solve your problem.
I'll give you that: That's not a bad hypothesis at all. Except the problem is, I've never had a problem recognizing when the problem is on my end. I know all too well people who just argue and argue refusing to accept that the problem really is with their OS or Ram or they didn't register the program or they don't have the right drivers or they didn't power on their PC etc..

I don't mind if the problem was on my end in fact, I wouldn't mind at all because then I'd 'know' the cause.

But I know for sure your test is not going to shed light on anything. We're not going to determine just how much more lag an USB gamepad have compared to a native Nes gamepad...we're not going to determine if the lag I described with Nestopia only happens on my PC setups or everyone's...we're not gonna determine anything at the end of the day with these tests.

Personally,I would probably try to investigate the vsync code and see if there would be anything that could cause such issues or not. But I figure you're gonna think it extremely insulting and annoying that a non-programmer give his opinion on the matter

Joined: Mar 2006
Posts: 17
R
Redx Offline OP
Junior Member
OP Offline
Junior Member
R
Joined: Mar 2006
Posts: 17
Quote:
Originally posted by R. Belmont:
Yeah, I've gotten the impression all thread that he was fishing for some specific "fix". Emulation doesn't work that way any more, we do things *right* :-)
Not true R.Belmont. If if 'was' determined that this was a side effect of proper, accurate way of doing emulation then I wouldn't want to see it changed just so people find it more enjoyable.

I always prefer the accurate way rather then the easy way. Which is why I praise at every opportunity emulators like Nestopia or bsnes (edit: and MAME and MESS for that matter). So you couldn't be more wrong on this one.

Joined: Jan 2006
Posts: 138
M
Senior Member
Offline
Senior Member
M
Joined: Jan 2006
Posts: 138
I've looked through my code for possible bugs and also tried to do some things differently, but in the end, nothing came up. Redx, I've lined up a few things you may want to check/try:

- Latest video and joystick drivers installed.
- Compare joystick and keyboard response time.
- Video driver option for triple buffering is OFF.
- Video driver option for VSYNC is set to be application-controlled.
- Instead of a triple-buffering option, some video drivers may give the user an option to specify how many frames to allow it to render ahead. Change it to the lowest value.
- Simply experiment with different settings in Nestopia (resolutions, turn off sound etc), including options that "wouldn't make any sense".
- Compare with older versions of Nestopia. Most interesting would be 1.09 since that's the last version that uses DirectDraw.

Joined: May 2007
Posts: 12
B
blz Offline
Member
Offline
Member
B
Joined: May 2007
Posts: 12
using Nestopia 1.36 with my Saitek 2500 with vsync & triple buffering on, I get as low as 193 visual and similar for audio, besting around 201 (and I don't have the most lightning reflexes either, lol).

Blarrg posted 189 for an NEW on a TV, and the latest version of Nestopia I feel no noticable input lag at all, I think it's safe to say this is pretty damn clsoe to a rela NEW box, and I must say the this is best damn NES emulator I've ever used.

Thanks a lot.

----
P.S. In 1.34 theres a video filter or two that doesn't show in list in 1.36 (options -> video -> filter), like 2xSaI... while I don't use them usually, sometimes I play around with that and am just curious what happened?

Last edited by blz; 05/08/07 05:43 AM.
Joined: May 2007
Posts: 12
B
blz Offline
Member
Offline
Member
B
Joined: May 2007
Posts: 12
Quote:
Blarrg posted 189 for an NEW on a TV,
NEW => NES (typo)

Joined: May 2010
Posts: 8
P
Member
Offline
Member
P
Joined: May 2010
Posts: 8
Originally Posted By blargg
I whipped up a quick reflex tester ROM which I hope to clean up another time. When run, it makes the screen white and waits for your to press A to seed the random number generator. It clicks and delays for 2-6 seconds, then clicks and makes the screen white. At this point you should press A as quickly as you can. It prints the number of milliseconds between the screen changing and you pressing A, then waits for you to press A to start another trial.

Take several times and average them for better accuracy, since the figure varies by many tens of milliseconds. On an emulator that only reads input once per frame, measurements will always vary by a multiple of 16.6666.

I took measurements for several setups involving my NES and an emulator on my PC with a CRT refreshing at 76 Hz. For each setup, I took 12 times and found the average. For audio, I used headphones.

Code:
189	Video, NES on TV
194	Video, NES on video capture
227	Video, emulator using custom serial joypad
236	Video, emulator using keyboard
254	Video, emulator using keyboard, vsync enabled
231	Video, emulator using custom serial joypad, vsync enabled
191	Audio, NES RCA out
254	Audio, emulator using custom serial joypad
Take your own measurements and post them with a description of what you timed.

reflex_timer.nes


Sorry I know this thread is 4 years old but I was wondering if anyone still has the reflex timer thing that blargg posted here (link is dead). I want to run some response time tests with a couple of my gamepads.

Thanks.

B
bugmenot
Unregistered
bugmenot
Unregistered
B
I second the request (he also posted another 2 test roms).

Besides, to add something to the discussion about input lagging,
i guess that gamepads connected with parallel port adaptors should lag less than any USB gamepad.

I've just done a very un-scientific test trying to play Crisis Force in co-op mode, pressing the same key on both pads at the same time.
The result was that the ship controlled by the pp-connected pad seemed to move first.
This result may be subjective, but there are many factors that suggests it is not:
- no parallel to serial conversion
- no data framing/enveloping is required, the CPU polls the port directly
I've always had the feeling that USB gamepads lags more than old PC game pads, maybe this is the price to pay for the ubiquity of USB.

[moderator note: illegal account, will be nuking ASAP].

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Re-uploaded files (I left off the first reflex_timer since I think the later two replaced it): time_nes_latency.zip

Joined: May 2010
Posts: 8
P
Member
Offline
Member
P
Joined: May 2010
Posts: 8
Thanks blargg

Page 1 of 5 1 2 3 4 5

Moderated by  Marty, R. Belmont 

Link Copied to Clipboard
Who's Online Now
2 members (Dorando, peter ferrie), 25 guests, and 9 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,100
Posts119,237
Members5,019
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com