Hacker News Reader

Hacker News

Comment by ferongr | Hacker News Reader

Parent Full thread

ferongr

Not until we can push data across distances faster than the speed of light.

The input and video latency makes it impractical for all but the slowest-paced of games.

View on HN

Your comment reminded me of:

I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?

From: http://superuser.com/questions/419070/transatlantic-ping-fas...

There is user-side latency and there is server-side latency. In multi-player games it may be preferable to have less latency within the game between players than in the players' view of the game.

You can send a packet to Europe and have it return faster than your fingers can respond to something your eyes just saw.

Note that this doesn't mean the latency is irrelevant. All latency is additive. Unless it's zero, matter how low it is, shaving away another millisecond is always worth it.

It's always beneficial, that doesn't mean it's always worth it. I could spend $300+/month on an internet connection with a tenth of the bandwidth of what Google's rolling out here (seeing that I don't live in Kansas City) and it would certainly be beneficial for me, but it's certainly not worth it

I have a line with that connection, and its only 50 euro a month (only in the cities though, out in the bogs its 8mb if you're lucky).

Depends on the distance. I have 14ms roundtrip latency to the closest google CDN -- that's less than what the typical monitor adds. Most of world's population lives in cities where putting up a game CDN is potentially worthwhile.

Errr. Have you tried it?

I've spent several playing first person shooters and it's easy to forget you're not playing locally.

There has to be latency issues, but as anyone that used to play Quake over dial-up can tell you: you get used to it.

A local client does not suffer from input latency and the client does not validate camera movement (mouselook) to server snapshots . There's also some leeway into other kinds of movement so latency jitter and a few dropped packets do not inadvertently disrupt the player's flow. Furthermore, the server does latency compensation that is crucial for actually hitting anything, especially with hitscan weapons lacking AoE damage. All the above is a very simplified explanation of what happens, more details at following PDF [1].

Games on OnLive lack the above features and you also have input lag, where, for example, a camera movement with the mouse will take the full network RTT plus processing time to reflect on the client's screen.

[1] http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/game...

That's true, I remember there being lots of prediction and compensation in QuakeWorld especially.

I haven't played the OnLive stuff so I'm not sure what it's like, but with a decent connection I'm guessing it's something that your brain just ends up dealing with. Although if it's anything like using RDC for a long period of time I can see it getting annoying.

Wow you just brought back memories. I remember when a 250 ping was fantastic :)

Give onlive a try... it really is on the level. AFAIK, they receive your input and process it server-side. What you get is in essence a live video stream. I am sure that it is more complicated in execution, but they make it work - and damn well.

Probably with a gigabit in bandwidth, it's possible that OnLive could use some kind of predictive modeling based on what you're currently doing and what you've done in the past to see what actions in the future are likely. It could then run (in parallel) all the likely actions and send them down simultaneously (example: simultaneously send what would be displayed if you panned right, left, up and down one or more frames before the user has given input and the client caches these frames and renders the one that the user ends up doing).

Sure it would be a "waste" of compute power and network, but that's certainly one way to, in a sense, "push data across distances faster than the speed of light". That's exactly the kind of approach which would be unimaginable in a scenario where you have to worry about compressing media in order to get a single stream across in a timely manner (read: now), but might actually fall within the realm of possibility when gigabit bandwidth is ubiquitous.

And then a cheating client will be developed that uses the information in these "alternate timeline" frames to alert you of enemies around the corner, etc.

I'm not saying that's catastrophic, but I think the impossibility of cheating is one of OnLives clear advantages. Sure you can write a bot, but it will only have access to the same information a human player does.

I think computing power would be a much bigger issue than bandwidth. You'd need to run many instances of the game for each user, and continuously kill and fork them.

And frankly, a $500 computer today can already display quite good graphics. Maybe by the time gigabit bandwidth is ubiquitous, computers will be usable enough that installing and running a game locally will be as seamless as clicking a link on a web page, so we won't need cloud gaming amymore.

> Not until we can push data across distances faster than the speed of light.

Ok, how is that possible? I genuinely am curious about the science. Feel free to provide links.

Well, going faster than the speed of light isn't possible, but if compressed really well, you could theoretically send massive quantities of data really quickly.

For example, if you want to play a game with someone who's on the other side of the world (or the galaxy) without that annoying lag imposed by relativity, you can simply have them send you a full scan of their brain, and then you can simulate it locally (not necessarily in your computer, it can run in the nearest Google MindSharing Center™).

Heck, you don't even need to play the game yourself. Send Google a copy of your brain too, and they will simulate the encounter in their servers and insert the memory in your brain when they're done. EVERYTHING can run in the cloud!

I'm pretty sure that was sarcasm.

The current approach is as follows: 1) User sends next action to OnLive. 2) OnLive renders the frame and sends it to the user. 3) Repeat.

The "faster than light" approach is: 1) OnLive renders several frames that could be the outcome of all the possible actions by the user, and sends all of them to the user. 2) User chooses the next action. 3) The frame is already available and is rendered ASAP. 4) The action is sent to OnLive. 5) Repeat.

It is of course not actually faster than light, but it's faster than the time required to send light to OnLive and back. Although, if you're going to this trouble, you may as well just render the frames locally and not bother with OnLive at all... :-S

Reply on news.ycombinator.com