Until round trips between the server and client are guaranteed to be under 50ms, the lag will feel unbearable. If someone is playing a racing game and has to deal with a second between the time they begin turning and the time they actually see it turn this service will be dead before it begins.

Having used the beta they are giving out right now on a random computer outside of their controlled settings I have to say that their technology works. Don't know what form of magic is involved but it is playable and actually really fun. I am all for the gaming experience being opened up to people without having to keep a bleeding edge gaming rig going.

"I am all for the gaming experience being opened up to people without having to keep a bleeding edge gaming rig going."

I'm all against it if companies don't have stand alone releases for PC anymore because it gives coporations way too much control over content, I can imagine Nvidia and AMD are not too pleased wiht online (i.e. no reason for a high end 3D card anymore) not to mention the insane lack of privacy. IMHO onlive is just customer lockin and hardcore DRM, I really hope it stays minority.

Completely agree with your last statement. The console majority has kept the game graphic specs low lately since they are running on 3+ year old tech (nVidia 7900 equivalent). So you can buy a card for $100, throw it in a cheap $400 HP or Gateway with a dual core CPU and a ton of RAM, and play any modern game at fairly high settings.

People need to ditch the misconception that they need a $1500 rig with an annual $300-$400 graphics upgrade. Simply not the case AT ALL.

I don't need $1200 worth of GPUs, but those curve-mapped polygons sure are shiny! It's also highly dependent on your display resolution. On a 19" to 22" display, the $100 cards do a decent enough job and you might not benefit from the higher quality settings anyway, but on a 27" LCD or HDTV, the extra perks a high-end GPU brings can make a pretty game absolutely dazzling. One great example is the recently released "Dirt 2" racing game. It runs surprisingly well on low-end hardware, but is absolutely jaw

having been an anon with absolutely no fact behind it I'm pleased to say that their technology won't work. From a bandwidth perspective it's not even feasible. Even 480P takes more bandwidth than they are claiming for 720p. 5mb/s for 720p? At what resolution, 320x200?

It's all hype, and anon #1 is damn correct.

There are a million problems with this approach, and it'll never work for the next 10-15 years. Someday, maybe, but absolutely not right now.

So someone claims to have used the system, and it's OK, and you just flat out don't believe him because he's anonymous?

Given the complete absence of blog posts etc. from beta testers since the beta started, I have to assume there's a strong NDA, so anonymous posting is appropriate. We should be glad he/she posted at all.

there isn't a strong NDA, there is just an absence of testing. The requirements for the beta are living within a very short distance of the beta testing area with a high speed connection (not just your average 6mb/s plan), if I recall correctly.

It's called cherry picking, and the phantom would like a word with you if you don't think so.

Almost nothing has been of good evidence about this. If that doesn't raise your vaporware sensors then I have a bridge I'd like to sell you. It's a really great bridge.

why have you seen nothing? because you never even searched. Helps to keep your eyes open if you're going to say you can't see something. First google result for "onlive review" pulls up a pretty recent result, aka this link:

I also strongly doubt that any kind of game on this platform can be enjoyed by people who are sensitive to input latency. For example my old high quality PVA TFT panel used an overdrive circuit to reduce ghosting. The overdrive logic in TFT panels usually buffers about 1 or 2 full frames to analyze and optimize the pixel voltages which leads to about 20-50ms input latency. I for one already notice it when I just work to the point where it annoys me when the desktop or terminal sessions somehow always feel sluggish, let alone fast 3D games.

I can't imagine that the complete round-trip time for sending my input over the internet, waiting for a frame to be rendered and encoded remotely, sent back over the internet, decoded and displayed locally would be less than 20ms and then you'd still have the latency of your display. It might be bearable with a very fast internet connection and a CRT display which has 0ms input latency.

Maybe others aren't that sensitive to latency and can enjoy at least slower games like turn-based strategy with this service. Good for them.

Edit: For those who doubt that you can notice such small delays, try this:- Connect an electronic instrument to your computer and artificially delay the audio by 30 ms.- Try to play accurately- ???- No profit.

I remember reading in the Time/Life book on the brain that adding an appreciable delay to the auditory feedback you get makes it very difficult even to talk properly. But I'm sure that's old research.

There doesn't seem to be that much on it on the net (or maybe I'm not searching properly). The WP article on Delayed Auditory Feedback [wikipedia.org] has a link to a paper with similar work but it is also from 1979.

There was an exhibit I remember seeing as a kid at the Boston Museum of Science in an area dedicated to exploring the human nervous system that did this. It asked you to attempt to read a paragraph of text into a microphone while your own voice was being fed back to you via headphones, slightly delayed. I remember it being extremely difficult to read the text properly.

I tell ya, does OnLive have to make their case every single Slashdot article or what?

Game engines have latency in them... OnLive runs those engines at faster than realtime, so when the packet from your controller gets to the engine 300ms later than it normally would the engine has plenty of time to do its thing.

All this was explained months ago when the technical questions were asked. This article is about the business question: when are you going to ship?

Game engines have latency in them... OnLive runs those engines at faster than realtime, so when the packet from your controller gets to the engine 300ms later than it normally would the engine has plenty of time to do its thing.

That's nuts. They can't run the engine out in advance of your input... unless they're rewriting core functionality of the engines, adding prediction like online FPS have. And... they aren't doing that.

If you have a ping of 100ms, you will press a key; 100ms later the onlive server will know you started turning. It generates, renders, and COMPRESSES a frame; sends it back to you. 200-250ms have elapsed. It will be like playing on a machine getting 5-10 frames a second.

Wait; I think I missed your sarcasm, grandparent post. Sorry. I've engaged in conversation with people in less technically savvy forums that think OnLive is possible, and so your comment wooshed right past me.

Don't feel bad: I bit too. It's just that there's so little decent trolling here any more that it's easy to confuse smart trolling with dumb earnestness. Also, those damn kids are playing their hippity-hop music too loudly on my lawn again.

Your normal ps3 you have on your entertainment system at home.. it has a controller plugged into it, right? It has a cable going into your tv, right? Ok, so here we go, you see something happen on the tv, you press the X button on the controller, the signal goes to the ps3, for the sake of argument let's say that signal takes NO TIME AT ALL.. it's perfectly zero. Ok, the PS3 does its thing and the rendered frames that are coming out

Assume 60 fps, synced with 60Hz monitor. That's 16.7ms per frame, and usually means a target budget of 16.7ms per iteration in the game loop - and input is probably processed exactly once in the game loop. Consider also that many decent displays already lag by a frame or two. So in a local hardware situation, you already have a built-in lag somewhere in the region of 30ms or so, pretending there isn't any lag in the actual hardware path between devices and what the OS surfaces to apps.

Now, given the above assumptions, but factoring in your posited reactive input model (i.e. no delay from game loop), you think that's good enough? The way I see it, it can only be good enough if the round trip averages to less than 16ms or so; and even then, it's not great. I've long noticed the lag in games since moving from CRT to LCD, and I can even see the lag between moving my mouse and the pointer moving across the screen - it's small but perceptible, and is either caused by the mouse / usb / driver path or by the LCD delay.

But I can't realistically see a 16ms or so round-trip being achievable outside heavily populated areas and without lots of expensive hardware very close to local loops. As it is, Google.com is 29ms away from my machine, and it's still slow to download the front page's HTML content - (yes, I know, TCP connection, several round trips, etc.) - on the order of 200ms or so.

It seems to me that round trips on the order of 50 to 100+ms are more likely, and delays of that nature are highly, highly noticeable in twitch FPSes - especially when it comes to things like changing the view direction. Pretty much all multiplayer FPSes don't wait for a server round-trip for changing the view direction. In that situation twitch FPSes will suck.

It seems to me that round trips on the order of 50 to 100+ms are more likely, and delays of that nature are highly, highly noticeable in twitch FPSes - especially when it comes to things like changing the view direction. Pretty much all multiplayer FPSes don't wait for a server round-trip for changing the view direction. In that situation twitch FPSes will suck.

Other kinds of games may work better.

You hit the nail on the head right there, the view direction.

Most games do all sorts of predictive wizardry to make the shooting work over internet latencies, but every game allows the view direction to occur completely locally, because even a slight lag makes the player feel like a drunkard. Many games also allow the local client to compute some of the 'game mechanics' locally, and then 'verify' the results with the server later.

Slightly offtopic, but that's exactly the solution I came up with when idly trying to think of a way for old multiplayer console games to be playable over the internet. (This assumes local graphics rendering and vastly superior hardware to the original console, which is not the case with the OnLive service.) Prediction can be done even when the core game engine wasn't designed for it, if the game is running inside a meta-engine like an emulator.

An attempt at rewriting reality. They were aiming at providing cutting-edge, high-requirement, high-definition action games to people with low-spec pcs. That's obviously ridiculous.

Setting their targets lower, to iPhones and such devices, may be a simple recognition on their part of the laws of physics. Good for them; they've gone from a service that's ludicrous to one that's simply niche. That's a new development

With bad latency you just can’t win! That’s a straight out fact. It’s as simple as that.

I remember back in the days of playing in the CounterStrike (even pre 1.0) league. I had around 30-40 fps. I changed some settings, got 60 fps, and suddenly ruled the game with a massive improvement!Yeah, that’s right: A 8-16 ms improvement in lag changed my whole game.And we don’t even talk about Quake 3 CPMA (pro mode) here. ^^

OnLive is probably expecting to become acquired by likes of Google or Yahoo that have servers everywhere and are able to cut latency to acceptable levels. They only need to prove their system is OK when server is few miles around.

They have been pretty open about latency issues. The server needs to be reasonably close (max 1000 miles) to keep round trip time below 80ms.

I am currently still a believer in this service. OnLive is not for the tiny hardcore gamers market who already have the best (expensive) equipment. I believe that OnLive might be able to get the casual gaming crowd introduced to high end gaming. Think Nintendo Wii target market, with PS3/XBOX360/High-end-PC gaming graphics. This market, not sensitive to the differences

They have been pretty open about latency issues. The server needs to be reasonably close (max 1000 miles) to keep round trip time below 80ms.

Well, they say 80ms and 1,000 miles. But first of all, even that seems a little dubious, for two reasons:

80ms is the very limit of the 'feeling of control' (before the lag gets to be too much). If they are always that close to the limit, noise will make things very bad, a lot of the time. Especially as more and more people sign up for the service (due to both load on their servers, and the network out of it).

80ms is the ping. But the ping isn't the entire story: Events happen on the *server* here, so the

If my hunch is right, OnLive won't need to be concerned over any TCP/IP stuff. The secret is all in the target market for the service.

My hunch says OnLive is going for a target demographic of -at minimum- people over the age of 80. They have already beat Halo 1,2 and 3 so for them, it is about enjoying the experience again. Latency and round-trip don't enter into consideration. When you pull that game you beat 2 weeks ago and reinstall it, do you care about how good it looks or plays? No! You just want to b

Many console games target 30fps, and console controllers are very ill-suited to twitch FPS gaming. No serious PC gamer would put up with such a low rate and will certainly the lag more with the richer control setup of keyboard and mouse.

It needs to be relative, as anyone having played Metroid Prime 3: Corruption on the Wii will know.

I disagree with this; I think the preference for relative motion is mostly just due to familiarity. The Wiimote doesn't really have enough precision to compete with a mouse for a FPS, although it's much better than any gamepad... but that's just an engineering issue. I've found the wiimote, or other objective pointing devices (like a graphics tablet) to be better for some games... shooting, real-time sims

Here's the reason: suppose I'm to go red-green-blue-yellow-orange-yellow-blue-green-red really fast (say, at the end of the TTFAF intro), and it's one big hammer-on-pull-off sequence which can't realistically be strummed (or the rules of the game have changed so I have to HOPO).

I miss the first green.

I only get to know that I missed the first green 500ms later. I have already HOPO'ed the rest of the sequence. There's no way I can go back in time 450ms and strum the blue I HOPO'ed, undoing the not-playing-correctly.

It's not just that you have to compensate for lag between inputs and outputs. You also have to make the lag inside a feedback loop very small. A minimal lag of 500ms is too much for rock band.... Even if the audio and video is perfectly synchronous, and the game compensates for the output lag by virtually moving your inputs back in time. The game can never move the reaction to the output, which happens in your brain, back in time to before the output.

At the risk of a "whoosh!", in context HOPO means "hammer-on/pull-off". When playing a Guitar Hero style game, ordinary notes are played by holding a colored fret button and pushing the strum bar. Some fast notes can be designated as "HOPO" notes, only requiring pushing the appropriate fret button if the previous note was played correctly. This is a simulation of the "hammer on [wikipedia.org]" and "pull-off [wikipedia.org]" methods of playing notes on a real guitar without strumming.

I'd imagine he gets it from reality. This service not only has bandwidth requirements but serious latency requirements. We're talking considerably higher than your average hardcore counterstrike player's latency requirements. Ala 60ms pings will be required and unless onlive plans to install itself in every single state, there's no way they'll make that kind of bandwidth.

See, it's not like streaming an application, where bandwidth isn't an issue (nor resolution), and it's not like streaming video, where lat

It doesn't matter how fantastical your software is. The internet as it is today in the US has very real limits. The numbers given by the parent are fairly accurate. It doesn't matter if you've got 50MB of bandwidth, the latency is still going to make those 50MB arrive too late.

Well they seem pretty confident they can manage 80ms. If so then it's got a good chance of working with most games, especially with console controllers. I seriously doubt you'll find anyone playing Quake 3 with mouse and keyboard though:p

I'm sorry, but nobody here has any reflexes fast enough to make anything less than 50ms perceptible. Or even 80.

I'm all for calling out people that have ridiculous and unverifiable standards, like the audiophiles that think they can detect MP3s compressed at a high bitrate.

However, that isn't the case here. A 50 ms lag can add substantially to the difficulty of a game. It's not purely reflexes; it's the timing of those reflexes. Let me put it this way... a thrown baseball travels a substantial dis

There are still no plans to support alternative platforms outside of Windows and Mac which is actually a bit disappointing. Onlive could have knocked out one of the major reasons why many people stay with Windows.

I can't help but think that the experience will be inferior to just buying the damned game, or at least renting it from an online service. Best-case latency is alleged to be 80ms, that's unacceptable for many types of game. In the real world, latency will vary and the experience will be inconsistent. When you add to this the fact that you can already get these games for Windows, it becomes unclear just what the point is.

Yeah remote desktops are the wet dream for outsourcing where I work. Imagine a system where the evil (cheap) foreigners see a video of the actual code so they can't take the revision history home on an SD card and sell it in the flea market for one tenth the real value!

Remote desktops seem to be the only real application for this; I doubt most fast paced games will work, until we've totally replaced the internet infrastructure. Strategy games and so on might work; but OnLive is trying to pitch high-spec fast-paced games, like Crysis.

I really can't see any way this is possible for action games. I've seen lots of people asserting it is, but never any sort of explanation that describes how they've circumvented all the obvious obstacles. (I believe the iPhone in the vid

If ofuscated text is easily readable (anti-captcha spam bots), text with not distortion at all will be perfectly readable, so if you send video, the other side will save that video (either with hardware or software) and use OCR to get back the text.

And after that you will have to reconstruct the document from the OCR output, which will take quite some time because people don't scroll by nice segments (i.e. by consecutive pages) while programming. And there's another issue, libraries. You can't OCR binary files which you don't see the contents of.

Your other responder mentioned OCR and libraries, but the other issue from the original post was that they would take the entire revision history, which is generally worth considerably more than the head revision (which might not even build at the moment, let alone work correctly!).

Yeah sure... replace a low-bandwidth, local application with a remote one that heavily relies on a fast network (and we all know it won't stop evil employees from taking business data where it shouldn't go). Sounds like a losing proposition to me. Am I missing something here, or are your bosses stupid?

Yeah sure... replace a low-bandwidth, local application with a remote one that heavily relies on a fast network [...] Am I missing something here

You're missing ssh + screen + emacs. That used to work fine on 9600 baud terminals; it should work fine over even a measly 1 megabit intertube. In fact, I know it does; I use ssh + screen almost every day (sometimes including emacs).

One of the key selling points of this service is directed towards developers and publishers: no piracy, and no used game sales. Every game played is controlled remotely. With movies or music, you could still record the media, but with interactive games in this fashion it's not possible. The key selling point to end users is you don't need the traditionally high-end hardware needed to play games. For the most part, other media plays fine on low-end hardware (high definition movies being a possible except

Ok, so in order to improve and maintain a consistent FPS rating (rendered, not just streamed), do you have to purchase "upgrade points". Basically, a virtual hardware upgrade for your virtual gaming rig session?

Yeah. Even it if was possible, which I doubt, it would still be a BAD THING (TM). It nullifies the only real advantage PCs have over consoles (modability and independent games), you lose the concept of owning a game... the graphics will have to be severely degraded, so you'll be getting an experience that will be worse than console graphics... it will only work for people that have a fast broadband connection, 99% of whom have fast computers and so wouldn't need OnLive anyway...

Yeah. Even it if was possible, which I doubt, it would still be a BAD THING (TM). It nullifies the only real advantage PCs have over consoles (modability and independent games), you lose the concept of owning a game...

OnLive doesn't nullify anything - it enables gamers who are below the bar of entry to play high-end games on their current hardware. Watch the video in TFA. The presenter plays Crysis on a Mac netbook and on an iphone. The customer who does this will not care about modding; he'll just be thanking his lucky stars he can play this game without having to invest in an entirely new platform.

This looks to me like a unique platform with its own advantages and shortcomings. It's not going to be all things to al

OnLive ensures that the game is running on a server that's got enough power for the game you've chosen. If it's Crysis, you might be the only player on a machine. If it's Peggle you might be sharing a machine with dozens of people.

You don't (conceptually) own/rent a "gaming rig". You buy the game, and the gaming rig is supplied whenever you play the game.

Analogy: you buy a meal at a restaurant. The provide the appropriate table, chairs, crockery

0 ms: User see on the screen his car moving left,200 ms: User press "D" to move his car right.201 ms: OnLive process the "D" and send the message to the server. The message is on the home router.251 ms: OnLive server receive the "D" command.301 ms: OnLive server generate the next frame.321 ms: OnLive server compress the frame, and send it to the client. The data is on the server router (80KB)(322 ms: User press "A" to move his car to the left.)371 ms: Home rout

0 ms: User see on the screen his car moving left,200 ms: User press "D" to move his car right.201 ms: OnLive process the "D" and send the message to the server. The message is on the home router.251 ms: OnLive server receive the "D" command.301 ms: OnLive server generate the next frame.

That all sounds good to me, but remember that the client and the server have a synchronized clock and the button press is timestamped, so when the server gets the message the game is rew

The "User press A" is because the problem ocurrs on the clientside wen the player overcompensate. A accelerator can have a delay of 1000 ms, and you will not notice, because the engine have a builtin delay, but If your direction have a 1000 ms delay, your car will move like you are drunk. Withouth "User press A", the experiment is somewhat moot point. The end result is that after the player ask the car to move left, the car will move right.

I still maintain that this simply can't work, and that it's an absolutely braindead money pit of an idea if it's not a total scam.

Idea: let's take the most latency sensitive, computationally demanding, and visually intensive thing you can do with a modern computer and try to apply the thin client model to it.

A single instance of the application in question will demand the full resources of the most powerful PC you can throw at it, but we'll just wave our hands and mutter something about virtualization to convince stupid investors that we have magic at our disposal. Because they are morons and because we put on a good show, they'll believe that you can somehow run many instances of a game on the equivalent of a single PC. We'll also be encoding 720p video in realtime at a quality / bandwidth ratio that no codec today can deliver; this will presumably happen on the same computing hardware that's already running multiple instances of cutting edge 3D games.

Finally, we'll throw in some shit about the iphone, because people can't stop fellating apple lately.

Anyone who believes this is technically feasible, much less economically viable, is fucking *retarded*.

I agree that on the face of it this looks like it won't work, but I can see many mitigating circumstances that means it just _might_ work.I think there's a small chance that they might actually be able to pull it off, and if they do it really is a game-changer.

A couple of things that makes me hesitant to call everyone "retarded" if they don't dismiss this before it has even seen the light of day:- They are aiming for The Long Tail of gaming, and I think it's easy to underestimate just how gigantic the amoun

The latency problem is of course the most apparent and thus the most discussed but there are others.

One I wonder about is what kind of servers they are supposedly using. The problem is that modern games demand a modern GPU to look good. The kind of processing needed cannot be done on any sort of reasonable processor in realtime. Also, GPUs aren't really set up to work in parallel these days. What I mean is if you try to have a system with multiple GPUs and running multiple 3D games on them, you are going to

Hell, MS would be interested in doing it non-virtualized. Be a cool selling point of a new Windows if you didn't need a GPU anymore.

DirectX has a software mode implementation (the Reference Rasterizer) that is included with the SDK. It is just as fast as one might expect (read: horribly horribly slow) but does the entire shebang in software. If you threw enough computing power at it, you could conceptually match GPU performance. However, this begs the question as to how much computing power they can afford to throw at it while keeping costs down enough to, at least, break even (a curse word to investors).

The one thing that isn't addressed here is if there is any software engineering going on to the games... my guess is that they need to do some rewriting to key parts of the software.

The whole point of a GPU is to handle specific, graphic related tasks, and that frees up the main processor to handle everything else. So why not have one set of servers that are tasked with processing data meant for a single GPU, another set that processes physics, and one that does sound, all that feed into another set that

I still maintain that this simply can't work, and that it's an absolutely braindead money pit of an idea if it's not a total scam.

Well it could work, but only for sedentary games where a bit of lag doesn't kill the experience, it might even offer some interesting scenarios for network play such as pitting one street or town against another.

Even so, the tech just seems to be a bit of a white elephant. Latency does limit what it can do, as will the sort of loads the server at the other end can tolerate. I

You obviously didn't watch the video at all. While you're being an asshole about the idea, the guy presenting during the presentation covered all of your strawmen.

1) "fill instance of the most powerful PC you can throw at it" - Uh, no. When you move from workstation class hardware to server hardware, the "ceilings" change. But, for games like Crysis, they do, indeed, use a big GPU per instance.

2) "720p video in realtime that no codec today can deliver" - Too bad you didn't watch the video. Turns out, this is the same team that brought us QuickTime before video codecs were even discussed. He also describes exactly how they pulled it off, started with scrapping the stream-based design paradigm, using a feedback loop based design paradigm, and creating a new encoder that looks great in motion encoded and decoded in real time (as one of the weaknesses, you can't pause it or it looks like shit).

3) "Presumably happen on the same computing hardware..." - Actually, no. As the presenter describes, the codec taxed even the dual quad core xeons that it was developed on. Then they fabbed custom chips that do nothing but implement the encoding algorithm. It's entirely hardware accelerated encoding, two chips per user on custom boards.

I also thought the entire process sounded like a big stupid scam, but before I declared the mighty victory of common sense, talking out of my ass, I went ahead and watched the video.

Did you watch the video? The first 5 minutes are all about overcoming latency issues and the architecture involved in that.

Do you know who Steve Pearlman is? He pretty much gave us QuickTime. He's got a history of incredibly forward thinking ideas, some took off, some didn't. This isn't like the Phantom console, where some MBA morons tried to do something. I don't think Pearlman would be out there showing this off unless there was some real meat going on here.

Great concept, I can't wait to play with it in person:) A few thoughts:

I'm a little skeptical about how robustly it will perform, but I am sure they will have a chance to prove their technology soon. I'm sure everyone who's played online has dealt with lag spikes, just due to random congestion, noise, route changes, that sort of thing. It seems that this system will be much more sensitive to those kinds of network delays.

One thing that they didn't talk about was really how high latency-sensitive games fit

I think the most interesting part was the (lack of) answer about how the compression works.

They claim 80ms round-trip latency from button push to image display. Running a game on a server and screen-scraping in ~20ms is fairly easy. With proper datacenter placement and peering agreements ~50ms round-trip ping times are reasonable (if somewhat optimistic). The issue is how do you compress the 720p image and send it back in 10ms with reasonable bandwidth.

They're claiming 1ms compression, 8ms decompression (125hz), and 5mbit 720p streams. The compression is using a custom ASIC, so that's completely believable. Decompressing at 120hz on any generic hardware (they specifically said no GPU help) means it has to be an extremely simple protocol. The biggest question is how do you reach "HD-quality" at only 5mbit when you are not doing group-of-pictures compression (keyframes and diffs from the keyframe). Mind you that a standard DVD is 10mbit, so they're claiming higher resolution with half the bitrate and no keyframing. Obviously H264 gets better quality/bit than DVDs, but it does so by using even more complex keyframing and diffs and is far too CPU intensive for their target platforms (it's hard to watch 30fps H264 trailers on many machines, let alone a 60fps stream). The only hint he gave was some mumbling about visual perception, and the statement that their compression only looks good in motion (if you paused the stream it would look terrible).

Exactly, their compression algorithim will have to be an absolute quantum leap in both quality and cpu efficiency i.e. magnitudes faster than anything else on the market.

And that's just the compression algorithm.

The oft hashed latency discussion aside (and I do believe colo is the only way this will be remotely possible), think about the logistics, how many hours have we all wasted getting game XYZ to run properly on hardware/driver/OS config ABC, now they have to do that for all the games they support....

Exactly, their compression algorithim will have to be an absolute quantum leap in both quality and cpu efficiency i.e. magnitudes faster than anything else on the market.

ISTR a broadcast pro posting that 1ms HD compression was becoming more common on live broadcast hardware. I find it believable, especially (as the GP pointed out) if they're making custom chips for the purpose.

And that's just the compression algorithm.

The oft hashed latency discussion aside (and I do believe colo is the only way this will be remotely possible),

They're entirely open about the fact that colo is their strategy. If you're not near one of their colo server farms, you won't be accepted as a customer.

think about the logistics, how many hours have we all wasted getting game XYZ to run properly on hardware/driver/OS config ABC, now they have to do that for all the games they support.... games that cannot be virtualised....

You're talking as if they get a boxed copy of a PC game and try to coax it to work on their system. It's not that at all. They make a deal with the g

Ya. A universal truth with new perceptually compressed formats seems to be that the more quality you want in a given size, the most you pay for it in terms of power needed to compress and decompress the data. You get trickier with the math and it gets you more for less, but at the cost of calculations.

In fact, you find that some seemingly "inferior" compressions were invented for just that reason. DV is a good example. It came around in 1995 for use in digital video cameras. However, when you look at it by

The ATSC A/53 standard in the US uses MPEG-2 for video compression. In July 2008 the A/72 spec was approved which supports H.264 as a video codec but I don't know any countries that have implemented that yet. MPEG-2 was chosen originally because the decoding was relatively simple which kept the hardware complexity fairly low. The A/72 spec is targeted at countries that haven't yet transitioned to DTV and the Mobile/Handheld spec which is meant to be similar to Japan's 1seg service so mobile devices can easi

Is to rent console time over the Internet, to people with enough money to have a PC that will run this stuff, and a fast Internet connection......or an iPhone, a platform known for its cost-effective pricing model......but don't want to buy their own console, because it would clearly be too expensive?

Of course, people don't want to all play computer games at the same time, so I can see they'll be balancing load throughout the day... erm... or not (and certainly, they're not going to be running connections internationally with latency that's anything less than abominable for this).

If they were going to bring PC gaming to consoles I could see an argument for hardware maintenance, but with the exception of the infamous XBox 360's RROD consoles tend to be built like a brick and go out of date long before they break.

What they're selling is the ability to play the latest games on maximum settings without ever having to upgrade your computer (or even have one - did you miss the very cheap hardware version they have for TVs?). You can even e.g. play Crysis from your netbook (or iPhone, as shown). It sounds like it might be worth it, depending on the price.

That said, I'm still very sceptical about the technical feasibility of the whole thing.

All these whiners claim latency will kill this before it ever starts. Guess what? FPS is not the only game category. I game all the time, but latency means nothing to games like Civ4, Neverwinter, and thousands of others. Sure, lower latency is a great goal to aim for, but this platform is a good step towards moving MMOGs onto lower powered clients. The games are just an excuse to extend their reach to more customers in a "new" way, so they can sell them things.

At least, not in any way, shape or form for people who don't live in close proximity to the servers. For me, I can usually get an average ping of about ~80ms to any given person or site on the internet; Even if the video feed had no additional overhead (and it invariably does), that still takes at least 80ms from when I send input and get to see a response on-screen, at the best of times. People already have issues with some LCD displays and input lag, and that's only on the measure of up to 10-40ms. Add in

Unless they have figured out how to go faster than the speed of light this simply can't work for action games. Their only hope can be to get bought by a cable company that would offer casual games or non-action games.

Right, because a small company with no products is going to be able to get large companies ot bend over backwards to make them a profit. Good luck with that.

Besides, unless they can change the network so that it doesn't have to follow the laws of physics, such as limiting the speed of electrons to the speed of light, this is more than just vaporware- its a fraud. And its our duty, as people technically capable of judging it, to point it out so that people aren't fooled into investing time or money on it.