Blur Busters Forums

Yea, i want to test my whole system including my monitor. I would also like to test my mouse in the total latency but i'm not too sure how i would do that.

It doesn't even look like you guys want to test systems and games anymore, your goal is just to achieve a 0us overhead and split the atom while you're at it.

Ah shit, i forgot to ask what it better/easier? the teensy or Arduino?

lexlazootin wrote:Yea, i want to test my whole system including my monitor. I would also like to test my mouse in the total latency but i'm not too sure how i would do that.

It doesn't even look like you guys want to test systems and games anymore, your goal is just to achieve a 0us overhead and split the atom while you're at it.

Ah shit, i forgot to ask what it better/easier? the teensy or Arduino?

They use the same chip(arduino micro/teensy 2.0), so given time they can both get to the same place. In this case Arduino/non arduino is more about the development environment. Many people use the Arduino development tools with a teensy. I think the Arduino development tools try to hide a bit too much from the user, so while it's easier to get started, it's harder to get down to the limits of what the hardware is capable.

In any case, you can look at the code for flood's and my input lag testers and see what's more to your taste.

they're equally capable but teensy is smaller

(since you can install teensyduino whatever on teensy, and it's not entirely necessary to use arduino libraries and stuff for arduino)

dx9test on main pc, using a crt:

https://docs.google.com/spreadsheets/d/ ... =639606112


edit: added lcd results for my viewsonic xg2703-gs (2560x1440, 165Hz )

it takes 10-35 white lines on the monitor to detect the light with my setup. brightness is max'd. so the additional input latency due to the sensitivity of my setup for this lcd screen is between 0.05 to 0.15ms.

so i believe this says that there's ~1.5 ms additional input latency from the monitor itself

Awesome stuff

Looks like a mixed distribution (uniform + skewed normal). I'm assuming the uniform component is due to the USB polling (min: 0 us, max: 1000 us).

Any guesses about what's responsible for the skewed normal?

Also, do we know anything about the amount of time it takes for the digital signal in video card to be processed by the DAC, in the case of the CRT?

when you add together distributions, the probabilty density function is a convolution, not summation

usb polling doesn't matter here. (explained in a previous post)

for now, all i know is that the long flat right tail for the crt results' histogram is due to vblank. i.e. when framebuffer is updated just as the screen is in the vblank part

no idea about dac performance. it could buffer a line or a few lines, which would add some 10s of microseconds.

flood wrote:when you add together distributions, the probabilty density function is a convolution, not summation

Ah, you're right. I was thinking of a mixture distribution, where each trial expresses only one of the underlying phenomena. In this case, however, each trial is the result of multiple phenomena.

Hey, would mind compiling the dx9 app for Windows for me please.

I did try and give it ago myself but i'm not really a pro and don't understand what's going on

http://i.imgur.com/A45QQDX.png

you're on 64bit right?

try this
http://www.filedropper.com/showdownload.php/test_343

left click or alt+f4 to close

Ah perfect!

I just had to make sure to turn off V-Sync and i'm good to go! My computer does have a 9999fps cap for some reason though but it's good enough!

Thanks mate!

Edit: my fault, Fraps only checks up to 9999fps, my fps count was 16000.