"David Gileadi" <f...@bar.com> wrote in message news:hb24km$pm...@digitalmars.com... > Nick Sabalausky wrote: >> Video game developers don't make multiplayer games by sending a >> compressed video stream of the fully-rendered frame - they know that >> would be unusable. Instead, they just send the minimum higher-level >> information that's actually needed, like "PlayerA changed direction 72 >> degrees" (over-simplification, of course). And they send it to a client >> that'll never insist on crap like interpreted JS or >> open-for-interpretation standards. And when there's a technology that's >> inadequate for their needs, like TCP, they make a proper replacement >> instead of hacking in a half-assed "solution" on top of the offender, >> TCP. And it works great even though those programs have visuals that are >> *far* more complex than a typical GUI app. So why can't a windowing >> toolkit be extended to do the same? And do so *without* building it on >> top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, >> etc.? > > This is generally true, although see OnLive (http://www.onlive.com/). I > hear it works better than you'd expect, but don't have much interest in > actually trying it.
Yea, I've heard of that. I'm extremely skeptical though. Even at *absolute* best, I still can't imagine it having less lag than one of those laggy HDTVs, which I already consider entirely inadequate for gaming. Plus they'd essentially have to have a whole high-end gaming rig (plus all the higher-end-than-usual video-capture/compression and network needs) for each simultaneous user, which I'd imagine would either make the subscription fee absurdly high, lead to 90's-AOL-style too-many-connection issues, or send them right into bankruptcy. It's just unnecessary bandwidth/latency bloat.