Hacker News Reader

Comment by jonny_eh | Hacker News Reader

I don't know where this is coming from. I can't perceive any lag in my unit when playing all sorts of games. I've hooked up an xbox 360 controller and there's no difference. There's no more input lag on an ouya than on an xbox 360 as far as I can tell.

There are a couple games built using an older version of the ouya Unity plugin that introduced some lag, so that might explain it.

Full disclosure: I am an employee of OUYA. But any developer that has had a dev unit for the past 3 months can chime in. We never got this feedback until a couple people in the press brought it up.

View on HN

> I don't know where this is coming from.

Polygon's hands-on review mentions this latency, along with a few other criticisms, including the feel of the controller:

http://www.polygon.com/2013/3/28/4157602/ouya-feature

I know where the statements are literally coming from, but not why they're saying it :)

> This was most apparent in the Ouya port of Canabalt. On iOS, Canabalt is a game of twitch reflexes. On the Ouya, I needed to react much earlier, knowing it would take an inordinate amount of time for me to get off the ground.

Have you guys not had the same experiences w/ Canabalt, or have you not heard any other reports of this?

I personally have a hard time noticing latency like some others report w/ games, unless it directly impacts gameplay (i.e. music games like Rock Band). I don't notice it on other games like FPSes, but many people are very sensitive to latency in games like this.

I just played canabalt on my OUYA devkit (I'm making a game for the OUYA), and I didn't experience any latency from the controller. A bunch of people played it last night when I demoed the OUYA at gamecity in Nottingham and no one complained about it then either. I haven't played canabalt on iOS and I'm not a big console player, so maybe I'm just not attuned to it

@jader I've got over 8000M in Canabalt, a personal high score on my ouya, much higher than I've ever got on my Nexus 4. If there was significant lag I don't think that'd be possible.

I've talked to the developers of the ouya port and they're baffled by these reports as well.

People subconsciously looking for something negative? No clue.

Yeah, I sometimes think sensitivity to input lag is very subjective. Also, another factor is the TV and/or receiver (if they have Ouya going through one). But surely Polygon editors would factor this in?

I'm not a game developer (or hardware expert), but are there not tests that can be performed to capture input lag? At least that way it could be ruled in/out at the hardware/software level, assuming you have a baseline reference of any input lag from TV/receiver.

John Carmack has done a bit of research on this, he has a good explication on SuperUser http://superuser.com/a/419167

Edit: Also on his blog http://www.altdevblogaday.com/2013/02/22/latency-mitigation-...

tl;dr High speed video camera capturing button input and screen in the same frame to measure the complete cycle. Diagnosing why is harder.

Doesn't HDMI give you the new and wonderful possibility of display lag? (This is particularly pronounced when playing games using iOS devices, especially older iOS devices, with AirPlay.)

Because the time between a frame being rendered and appearing on screen can increase, you are reacting slowly to events on the device which you perceive as control lag when in fact it's display lag.

Compliant HDMI shouldn't introduce any latency itself. It's just a digital signal, no different in principle than the signal from a wired game controller. Where latency can creep in is a TV's image processing algorithms – a color adjustment algorithm might add a few milliseconds, an edge enhancement might add a few more; a 120hz motion compensation system will add a lot more.

Most TVs will allow these to be disabled (often in a specifically labeled "game mode") but a few may inexplicably not allow them all to be disabled, hardwired for a certain degree of latency.

AirPlay, on the other hand, introduces a lot of latency because it's compressing the image prior to transport and uncompressing it on the other end. This generally introduces significantly more lag than any TV image processing.

Here's an article on how to detect and measure the effect I'm talking about.

http://www.pcworld.com/article/183928/how_to_find_and_fix_in...

It's a consequence of using framebuffers in the display device. I mentioed Airport because it exaggerates the effect, but any digital display will likely introduce s little extra lag.

I don't think mortenjorck particularly disagrees with you.

I think they are reading [HDMI] specifically as [HDMI] rather than [The use of an external display, via HDMI].

Sorry I can't reply to you directly, but:

EXACTLY. HDMI encodes frames and pipes them to the TV which has to render them. There's no guarantee this will be instantaneous (indeed it's virtually guaranteed that it won't).

Incorrect. HDMI is a standard for transmitting uncompressed video, same as DVI. Raster goes in one end and out the other. AirPlay, on the other hand, does encode frames that need to be uncompressed by a renderer.

not to mention go through your congested wifi network.

Compressed or uncompressed doesn't matter. The point is that the display device is buffering frames and then rendering them later (ideally imperceptibly later).

Airplay definitely adds more potential bottlenecks but the principle remains the same.

But the buffering is not required because of the HDMI link; a display could update each pixel as it receives it over HDMI, just like CRTs did. LCDs buffer at least one frame for many reasons, but "because HDMI requires it" is not among them.

And compressed vs. uncompressed does matter, especially when you're talking about video compression. Because compression requires some minimum amount of data before it can even begin to compress, let alone start to send the compressed bitstream over a physical link. And then you have more latency as you add a decode step. Not to mention the complete lack of latency guarantees a wifi link has...

>Compressed or uncompressed doesn't matter

it most definitely does. With DVI/HDMI each frame sent is just that, a frame. at X the screen should be Y. If a frame is damaged/lost you have only lost the information from that one frame (or just part of the frame).

However with compressed data each frame is now intertwined with neighboring ones. if you lose a frame or its damaged, you have now have lost X frames until the dependent frames are past.

I'm not sure if you've ever had the experience of a damaged HDMI cable, but you can see the exact pixels that are affected, and they change frame to frame as you twist the cable making it worse or better.

Compressed video is like Netflix or a damaged AVI where when the corrupted data is hit the entire stream goes wonky for a short while until it suddenly snaps back into clarity when a keyframe is hit.

Uncompressed is as near real time as you can get, the video is directly passed through. Compressed you have a buffer, decoder, etc and there is more delay/processing.

In practice no digital TV actually works like this. The screen isn't instantly updated the moment the pixel data arrives on the line (which is exactly how analog CRTs work, which is why you have to adjust vertical hold, etc.)

You can still get lag on CRTs — phosphors don't light up instantly — but digital TV adds all kinds of opportunities for screwing up timing, and ironically it's the fancier TVs that do more processing (e.g. Interpolating frames, decoding 3D, et .).

I agree that display lag can be an issue. But HDMI is not the cause. Sluggish post-processing in the TV is (if it does color correction, sharpening, noise filtering, etc. etc.).

I know other people have already talked about screen lag, but I just wanted to mention that this is well known in the Super Smash Brothers community. LCD/HD tvs are not usually used in Super Smash brothers tournaments because of the noticeable lag. http://super-smash-bros.wikia.com/wiki/Lag#Screen_Lag

While its possible the controller lags, it seems a little more likely that the lag is caused from the transition from the iPad screen to a lagging LCD screen.

Maybe it is video lag? (i.e. their TVs are adding the lag, not the controllers.)

Since the controller uses Bluetooth, it's sending packet data over 2.4GHz with error correction. Perhaps if you're in a Wifi-congested environment, you get more error packets, leading to a reduction in sending speed or more time spend retrying. That could be one difference between the Ouya lab and the laptop/console-filled halls of a gaming website.

Reply on news.ycombinator.com