Ben Heck's latest device isn't gonna help you take your next-gen gaming on the go, nor will it let you play with one hand. Instead, the Xbox 360 Controller Monitor is designed to test gamepad latency using a data cable hooked up directly to each button and fed into a 8 x 8 inch display board. Each action lights up the corresponding indicator, and it includes three levels of sensitivity for each cardinal direction of the joysticks and shoulder triggers. At $600 (controller and AA batteries included), it's not exactly something for the hobbyists out there, but already this thing's got some major gaming street cred: it's currently being used for playtesting on Mass Effect 2, the new Wolfenstein, and the just announced Modern Warfare 2.
You could do that, but the purpose of this is to allow developers to judge latency from human input to game reaction, it's designed to be used while playing so that the developers can make adjustments to latency as required.
I would assume that is basically what it is used for. My guess its to test the latency of inputs in regard to what happens on screen. Probably to measure the delay between the input on the controller and the output from the game.
It's made to read the buttons directly from the controller as you press them, to calculate the typical latency of such a controller, from the moment you push it till the moment something happens on the screen.
Videotape it next to your screen, calculate the difference of time between the moment the LED lights up and the moment where something happens, and you got your latency. Latency is as all FPS players know a huge problem if it gets too high and monitoring it might be useful to take account of controller lag when you play against bots.
I made something similar to this a few years back with a ps2 controller, different desired effect but very similar all the same. Mine, made my gaming better to me. Ben, ya interested? I'll have to dig it out of the old mod trunk, er cardboard box...
I still don't get what use this can have. Yeah I understand that it measures latency, but surely that is going to be different when sending the commands to a console than it will sending them to light up an LED. It would be much better to have a latency program on the actually console replacing the hardware one, at least that would give you a more accurate representation of what you'd experience during game play.
Any serious company that is using this to test their games gets a -1 from me.
sending it through the console would defeat the purpose as this is designed to see how long it takes the console to process the signals and apply them as explained earlier, and since a 2 foot trip through the ribbon cable is quicker than wireless encoding, decoding and processing through the console, it allows you to see just how long that takes and adjust the game code to allow that to take less time.
This is actually very useful, and there are reasons why you don't want latency measured at the system software level. As some other posters mentioned, you would video capture the screen and the output from this device at the same time, and then you can count the frames between a button being pressed and the resulting action being seen onscreen. It's not uncommon to have several frames of delay introduced by layers of UI tools or checks running in parallel, so this is the only way to measure true objective latency. Sometimes something you do will access some part of the system, which wouldn't be reported as any delay by the system (as it's frozen essentially) but this would give you accurate results. Then you start investigating why, and try to improve the user experience.
And for the record, the companies that are really serious about user experience have been doing this for a long time, with a number of different methods. We count frames so you don't have a 6 frame delay where it's really important and maybe we can get that down to 3. It's not something that you can easily even feel--it's just "off" for some reason, and that reason can be input lag.
I'm pretty sure that the lights on the board are MEANT to have 0, or at least next to 0 latency, and you would simply measure the time between the LED on the board and the reaction from the console to determine latency.
As he said, the LEDs are wired directly to the inputs. So it doesn't measure controller latency at all, because it's not accounting for the time it takes the signal to be transmitted and received wirelessly. A pretty useless gadget, you could build this from parts from digikey for around $15. It doesn't even need a microcontroller to do any decoding.
I just want to clarify in case you didn't read it elsewhere.
When it is said that this device is used for measuring latency, they mean that it is used as a zero point reference. You can not easily monitor the pressing of a button by videotaping the hands of a player for several reasons (obscuring the image with their hands, a vague definition of how depressed the button must be etc). This board (which as is stated in the video is made larger for easy filming), is not designed to measure the controller latency... that would be pointless, if such a device existed once a single test was done (or a few) the values found could be shared with all.
Instead this board is set up beside a screen displaying the game. Let's say that, for example, the melee feels a little bit slow in your FPS de jour, as a play tester, it is one thing to say this... but for the developers to actually see the delay... ie. watch the video frame by frame and see how many frames after the melee button (B, stick click etc) before the animation is started in the program. In fact, with a diagnostics screen open it could be even more accurate... instead of looking for the start of the animation, they can look for when the animation actually starts.
The delay of the controller due to its wireless nature is a limitation that programmers can't really get around, but stiff/sticky controls that are the results of many layers of code from intput to animation can be improved... and I'm all for it!
This is a video of mine. Showing different tests with different settings applied on the PS3. I used the Casio EX-FH20 to capture the video at 240 frames and than counted the frames afterwards.
The estimated number of Xbox 360 consoles that fail within two years of purchase.
A new study from SquareTrade found that just 23.7% of Xbox 360 consoles failed within the first two years of ownership, which is actually a fair bit better than some of the previous numbers that topped 50%.
Now that we've thrown 'em off the trail, use the form below to get in touch with the people at Engadget. Please fill in all of the required fields because they're required.
posted Mar 26th 2009 7:54PM
i don't think i have that kinda money
Post jack, but where's the continuation of the PS3 laptop tutorial?
Cool to see that something he makes at home is already being used by pros in the industry. Well done.
My guess?
He's probably so rich right now.
*buying one for my kid*
i dont get it though... you could do the same with with xpadder on a pc and a wired 360 controller... why is this such a big deal?
You could do that, but the purpose of this is to allow developers to judge latency from human input to game reaction, it's designed to be used while playing so that the developers can make adjustments to latency as required.
ben heck consistently amazes me.
Amend to that!
I'm pretty sure Jonathan's comment doesn't need amendment.
But if we had an edit function, at least the possibility would exist. ;)
I sooooo glad that I don't have any kind of use for this.
i dont get it. whats the purpose?
just to clarify, this thing is amazing and very well put together. i just dont see a purpose for it lol
it's for developers to test their games...
i think to register the time difference between when the button is pressed and when it is registered in the game. unless i'm misunderstanding.
like goped said....whats the point?
those are some sweet street creds
So um yeah. What exactly is this used for? Just so someone else can see what buttons are being pressed at the time??????
I'm quite in to tech and all but don't see a real practical use, please explain this better if anyone has a clue, thanks.
I would assume that is basically what it is used for. My guess its to test the latency of inputs in regard to what happens on screen. Probably to measure the delay between the input on the controller and the output from the game.
thanks, I get it now. The post below really explains it also
It's made to read the buttons directly from the controller as you press them, to calculate the typical latency of such a controller, from the moment you push it till the moment something happens on the screen.
Videotape it next to your screen, calculate the difference of time between the moment the LED lights up and the moment where something happens, and you got your latency. Latency is as all FPS players know a huge problem if it gets too high and monitoring it might be useful to take account of controller lag when you play against bots.
I made something similar to this a few years back with a ps2 controller, different desired effect but very similar all the same. Mine, made my gaming better to me. Ben, ya interested?
I'll have to dig it out of the old mod trunk, er cardboard box...
I still don't get what use this can have. Yeah I understand that it measures latency, but surely that is going to be different when sending the commands to a console than it will sending them to light up an LED. It would be much better to have a latency program on the actually console replacing the hardware one, at least that would give you a more accurate representation of what you'd experience during game play.
Any serious company that is using this to test their games gets a -1 from me.
sending it through the console would defeat the purpose as this is designed to see how long it takes the console to process the signals and apply them as explained earlier, and since a 2 foot trip through the ribbon cable is quicker than wireless encoding, decoding and processing through the console, it allows you to see just how long that takes and adjust the game code to allow that to take less time.
This is actually very useful, and there are reasons why you don't want latency measured at the system software level. As some other posters mentioned, you would video capture the screen and the output from this device at the same time, and then you can count the frames between a button being pressed and the resulting action being seen onscreen. It's not uncommon to have several frames of delay introduced by layers of UI tools or checks running in parallel, so this is the only way to measure true objective latency. Sometimes something you do will access some part of the system, which wouldn't be reported as any delay by the system (as it's frozen essentially) but this would give you accurate results. Then you start investigating why, and try to improve the user experience.
And for the record, the companies that are really serious about user experience have been doing this for a long time, with a number of different methods. We count frames so you don't have a 6 frame delay where it's really important and maybe we can get that down to 3. It's not something that you can easily even feel--it's just "off" for some reason, and that reason can be input lag.
I'm pretty sure that the lights on the board are MEANT to have 0, or at least next to 0 latency, and you would simply measure the time between the LED on the board and the reaction from the console to determine latency.
As he said, the LEDs are wired directly to the inputs. So it doesn't measure controller latency at all, because it's not accounting for the time it takes the signal to be transmitted and received wirelessly. A pretty useless gadget, you could build this from parts from digikey for around $15. It doesn't even need a microcontroller to do any decoding.
I just want to clarify in case you didn't read it elsewhere.
When it is said that this device is used for measuring latency, they mean that it is used as a zero point reference. You can not easily monitor the pressing of a button by videotaping the hands of a player for several reasons (obscuring the image with their hands, a vague definition of how depressed the button must be etc). This board (which as is stated in the video is made larger for easy filming), is not designed to measure the controller latency... that would be pointless, if such a device existed once a single test was done (or a few) the values found could be shared with all.
Instead this board is set up beside a screen displaying the game. Let's say that, for example, the melee feels a little bit slow in your FPS de jour, as a play tester, it is one thing to say this... but for the developers to actually see the delay... ie. watch the video frame by frame and see how many frames after the melee button (B, stick click etc) before the animation is started in the program. In fact, with a diagnostics screen open it could be even more accurate... instead of looking for the start of the animation, they can look for when the animation actually starts.
The delay of the controller due to its wireless nature is a limitation that programmers can't really get around, but stiff/sticky controls that are the results of many layers of code from intput to animation can be improved... and I'm all for it!
This is a video of mine. Showing different tests with different settings applied on the PS3. I used the Casio EX-FH20 to capture the video at 240 frames and than counted the frames afterwards.
http://www.youtube.com/watch?v=1jGW2uA9iXw
These types of devices are very necessary. I'm glad Ben Heck made this device.
They should have used this on killzone 2.
This is pretty old. He's actually done this a very long time ago.