What is your opinion about the new On Live game service?

[Niode]

The biggest problem in my mind is latency. Between the latency between your input and it being registered on the server a thousand miles away, the latency inherent in video and audio compression, and the latency of sending the updated video and audio to your machine, I can't see this as being terribly playable for anything other than FPSs, where people are already used to terrible latency, or RPGs, where it doesn't matter that much.

But yeah, the idea is unappealing to me for a lot of other reasons, too.

Speak for yourself, maybe on that piece of shit game Modern Warfare 2 where all online is P2P, but on most games I expect lower than 100ms, bare minimum. Unless the OnLive guys have invented a new kind of electricity then the latency they say they can achieve is just complete bullshit. The latency between PS3 and Dualshock 3 is around 66-100ms (depending on frame rate). They say they can achieve better than that with a server hundreds, possibly thousands of miles away? BULL-FUCKING-SHIT.

[Limewater]

Speak for yourself, maybe on that piece of shit game Modern Warfare 2 where all online is P2P, but on most games I expect lower than 100ms, bare minimum.

You don't think more widespread online play hasn't conditioned people to accept high latency in First-Person Shooters? I guess I never viewed them too much as high precision games the way, say, Contra is. FPS control always feels pretty loose to me, though that's partly a result of a decent Physics model, I guess. However, I'm not a huge fan of the genre, so I guess I don't have that much experience compared to a lot of others.

The latency between PS3 and Dualshock 3 is around 90-100ms.

Seriously? I have a hard time believing that. Where did you get that number?

But now, I don't think they would need to invent a new type of electricity to maintain sub-100 ms latency. I don't see how they can do it over existing network infrastructure, though.

[Niode]

Speak for yourself, maybe on that piece of shit game Modern Warfare 2 where all online is P2P, but on most games I expect lower than 100ms, bare minimum.

You don't think more widespread online play hasn't conditioned people to accept high latency in First-Person Shooters? I guess I never viewed them too much as high precision games the way, say, Contra is. FPS control always feels pretty loose to me, though that's partly a result of a decent Physics model, I guess. However, I'm not a huge fan of the genre, so I guess I don't have that much experience compared to a lot of others.

The latency between PS3 and Dualshock 3 is around 90-100ms.

Seriously? I have a hard time believing that. Where did you get that number?

But now, I don't think they would need to invent a new type of electricity to maintain sub-100 ms latency. I don't see how they can do it over existing network infrastructure, though.

Read the link I put in my post. It explains it all. At 60fps there's at least a 4 frame lag, and it gets worse the lower the frame rate. If input lag is that high when your controller is just a few feet away from the machine, then just think how bad the lag will be when you're sending inputs hundreds of miles away, and then receiving a video back.

OnLive will not work. At all. Trust me. I will eat my entire game collection if it works.

[yomomma1]

Wait.... Wait. So onlive is faster than the controller's input? That must mean... that onlive uses a gypsy to predict the future!

[Niode]

Wait.... Wait. So onlive is faster than the controller's input? That must mean... that onlive uses a gypsy to predict the future!

Yeah, either that, or y'know, they're lying. *collapses in a state of shock*

[Limewater]

Read the link I put in my post. It explains it all. At 60fps there's at least a 4 frame lag, and it gets worse the lower the frame rate. If input lag is that high when your controller is just a few feet away from the machine, then just think how bad the lag will be when you're sending inputs hundreds of miles away, and then receiving a video back.

OK, I read the article and now I see what's going on. You're not really describing the latency between the controller and the console. You're describing the latency between the controller and an onscreen representation of the state of the controller. That's a lot different, and can explain the inconsistency.

From reading that article, all I could conclusively say is that latency between the controller and console is definitely less than about 66ms. If I had to guess, I'd say it's probably in the neighborhood of 15-20ms to represent controller polling at either 50 or 60 times per second. However, if one felt the need to have lower latency between the controller and the console, it could be accomplished pretty easily.

OnLive will not work. At all. Trust me. I will eat my entire game collection if it works.

I will also be surprised if it works well.

On a dedicated network, I could actually believe that 80ms figure. Again, I'm pretty skeptical that it can perform well over existing infrastructure.

[fastbilly1]

Niode you are forgetting that Onlive using Scyring stones in a Stargate in the Sphere. It cant not work, its running on linux.

Im with Niode on this one. Ive been gaming online since my parents had a baud modem and this just sounds too good to be true. If it works, awesome, but Ill stick with GoG and Steam.

[Ivo]

My opinion, based on my guess on how it will work (i.e. not well):

It is a good idea, implemented badly in terms of pricing, and I seriously doubt the technology is ready. This kind of stuff may or may not be "the future" (or a significant market share part of the future) when they work out better pricing and the tech can support it decently.

Ivo.

[Niode]

Read the link I put in my post. It explains it all. At 60fps there's at least a 4 frame lag, and it gets worse the lower the frame rate. If input lag is that high when your controller is just a few feet away from the machine, then just think how bad the lag will be when you're sending inputs hundreds of miles away, and then receiving a video back.

OK, I read the article and now I see what's going on. You're not really describing the latency between the controller and the console. You're describing the latency between the controller and an onscreen representation of the state of the controller. That's a lot different, and can explain the inconsistency.

From reading that article, all I could conclusively say is that latency between the controller and console is definitely less than about 66ms. If I had to guess, I'd say it's probably in the neighborhood of 15-20ms to represent controller polling at either 50 or 60 times per second. However, if one felt the need to have lower latency between the controller and the console, it could be accomplished pretty easily.

Yeah but that's the thing, that is exactly what is going on, you have your initial lag input from the controller to the onlive box/client, which is going to be around 10-20ms, then there is the lag from the onlive client to the server, which at best going on best possible scenario IE you have a server a couple of miles away is going to lead to a minimum of 35-40ms. That's 50-60ms already, and we haven't seen the result yet. You are then subject to input lag within the game engine from receiving input from your client. Adding another (according to digital foundry) 60-200ms depending on game. Then the server has to encode the resulting video feed and transmit it back to your client again, suffering another 35-40ms (at best) lag, then the onlive box/client then has to decode that stream and display it on your TV suffering another 5-10ms lag. All in all we're up to 145-310~ms, and that is best possible scenario, which is something they cannot achieve on current mainstream telecoms infrastructure.

Not to mention that netcode (which helps alleviate lag within online streaming situations) is based on prediction, the best netcode either pre-caches upcoming content (something that onLive simply cannot do, it's impossible given the nature of games and how they work) or in a gaming context predicts every single move an opponent can make ahead of time and then displays the results when the user commits to a path. That's the reason why when we experience 'lag' as an anomaly, you see the opponent jumping from one location to another as the netcode catches up. OnLive benefits from neither example. It's impossible. The amount of bandwidth required to do such a thing would be immense. Bearing in mind that the server would have to pre-render every single possible move ahead of time and transmit them simultaneously so that the client can choose the best path. Something that would be possible in simpler games or say jRPGs where every decision is basically based upon menu choices, the math can be done in advance before the action unfolds on screen but for action games it simply is not possible yet, and likely will never be.