OnLive games service 'will work'

[gingerjedi]

http://news.bbc.co.uk/2/hi/technology/7976206.stm

I can’t see how?

OnLive turns games into video data sent across the net to a hardware add-on, or software plug-in, which decompresses the data back into video.

Even basic X,Y movements that use very little data lag so I can't see how you can effectively host the entire game remotely? Surely it’s like running an Xbox processor with a 2Mbps FSB? Even at 100Mbps it would be crap.

[Solidec]

Won't work, next!

[DaveB]

http://news.bbc.co.uk/2/hi/technology/7976206.stm

I can’t see how?



Even basic X,Y movements that use very little data lag so I can't see how you can effectively host the entire game remotely? Surely it’s like running an Xbox processor with a 2Mbps FSB? Even at 100Mbps it would be crap.

Depends on how clever they have been with the data compression. If they have taken a leaf out of the Metaframe book and are only compressing and transmitting those parts of the display that are actually changing with each frame then the requirements come right down. Not retransmitting stuff that hasnt changed makes a big difference and will give much better framerates than rendering the whole screen each time.

Latency in response to inputs from the player should be no worse than for any other game. If a normal online shooter gets laggy due to network latency then response drops regardless of whats going on on the screen although frame rates for the player remain unchanged.

[b0redom]

BUT in a FPS or racing game, pretty much the whole screen would be changing all the time.

[gingerjedi]

Chess would be ok.

[chicane]

"The round trip latency from pushing a button on a controller and it going up to the server and back down, and you seeing something change on screen should be less than 80 milliseconds."

Oh dear. An 80 millisecond lag would be unworkable for most racing and FPS games.

Perhaps they're intending the future of gaming to be a pleasant game of chess over a streaming video link.

[DaveB]

BUT in a FPS or racing game, pretty much the whole screen would be changing all the time.

Actually they would be easier as the backgrounds tend to be static, prerendered images, as do the player avatars and vehicles. The stuff that causes problems are the effects such as explosions, environmental effects like smoke etc but as a precentage of the screeen real estate it's still a relatively small amount that is changing each frame. Doing it in custom silicon will make a big difference as well compared to the conventional software processes.

It still may not work, but I dont think it's as much of a non-starter as is being made out.

[DaveB]

Oh dear. An 80 millisecond lag would be unworkable for most racing and FPS games.

Perhaps they're intending the future of gaming to be a pleasant game of chess over a streaming video link.

"We usually see something between 35 and 40 milliseconds."

Which is perfectly acceptable.

[chicane]

Actually they would be easier as the backgrounds tend to be static, prerendered images, as do the player avatars and vehicles.

Are you sure you know what you're talking about?

[gingerjedi]

I think he means the basic structure of the 'map' doesn't change even though the players perspective obviously does, the trouble is we were moving towards dynamic destructible environments with 50+ players, I can't see how this could cope with all that.