You have people complaining about touch-lag on Android devices, which is on the order of 100ms, and you're telling me you're going to send a packet with a controller movement, render a frame, compress a frame, ship it back, and display it with something <100ms? The demo shown is a non-interactive cut-scene, so no one's going to notice the input lag. OnLive, when latency was actually measured, came out around 150ms, totally unacceptable.
Th true test would be running something like CoD, BF4, or a SF2 tournament and get pro gamers to evaluate the system.
The AAA titles are never going to be run this like economically. I'm playing Battlefield 4 right now, a huge huge game that brings my current PC rig to its knees. Why would anyone want to suffer this with 150ms lag and compression artifacts?
Apart from finding a way to profit from this there are no big problems left to solve.
A fast enough pipe (100Mbps fiber is quite common and cheap here in Europe) could deliver good results, even if the whole world is rendered and then streamed as video.
So when you're playing an FPS and you press a button to shoot, the local game logic and physics computes and displays the result immediately (firing animation, sound start playing). A short delay later, the server confirms a kill.
Even with this fairly sophisticated model, you still want <50ms pings. Video streaming and running the entire game in the cloud just won't work for games that require rapid hand-eye coordination.
Systems like onLive are capable of bringing high-end graphics to low powered devices like tablets, netbooks, and notebooks, phones even.
And keep in mind that 150ms will reduce as our technology gets better and more servers get deployed.
https://aws.amazon.com/marketplace/search/results/ref=gtw_na...
However, when they originally announced this in May, my impression was that this was going to be open sourced and a part of Firefox. I found that to be really exciting.
It turns out, it's just another business trying to show us the future. Nothing wrong with that but it doesn't excite me as much.
Also, Brendan Eich is an advisor to Otoy, the company behind ORBX.js. Is it just me or does anyone else think that it's a conflict of interest for him to market a for-profit service/product via Mozilla? It's not clear what exactly Mozilla's involvement is in this project and what do they get out of it besides a broader web ecosystem?
The only really exciting thing going on in gaming (for me) is the Oculus Rift. Outside of gaming maybe there are other use cases. Given how powerful and cheap hardware is, I just have a hard time believing it'll take off.
OTOY’s CEO Jules Urbach demo’ed an entire Mac OS X desktop running in a cloud VM sandbox, rendering via ORBX.js to Firefox, but also showed a Windows homescreen running on his Mac — and the system tray, start menu, and app icons were all local HTML5/JS (apps were a mix ranging from mostly local to fully remoted, each in its own cloud sandbox).
Personally I find that much more interesting than anything to do with gaming.
So what's the minimum bandwidth you need?
It took me a few tries (and a couple hours) to get one of their preconfigured AMIs provisioned, excruciatingly extract the GUID from Win2k8 (people actually work this way?), but now their weird HTTP bouncer endpoint doesn't seem to be connecting at all..
nothing.
Just like you said. It doesn't connect using their prescribed aws.otoy.com link.
I'm waiting to see if anyone actually ever gets this to work.
wmic PROCESS get Caption,CommandLine | FIND "GUID"
but write the results to a txt file on the desktop. So...
wmic PROCESS get Caption,CommandLine | FIND "GUID" > Desktop\t.txt
I don't know why OTOY would NOT have put that value in the instance metadata on startup???
of course im taking this out of my arse from just watching the videos with maya running in a browser.
Instead, imagine VNC, but programmable with Javascript across applications in a standard way.
Imagine using a remote app, but when a particular trigger occurs (think a special button on the client) it opens up a new connection to another server, and splices the connection into the view, so you can use apps on the two servers at the same time.
But there is plenty more - Javascript can inspect individual frames, and use them as triggers for other actions.
Advertisers haven't figured out how to embed ads into your standalone VLC experience yet.
It's revolutionary- for the advertisement market.
>A single GPU, Amazon argues, can support up to eight real-time 720p video streams at 30fps (or four 1080p streams).
Seriously? I have been working on X11 support in Gate One for a while now and my laptop, with absolutely ZERO GPU acceleration can deliver/encode 720p, 30fps video to a browser at around 5% CPU utilization.
Proof: http://youtu.be/6zJ8TNcWTyo
Companies like iSwifter have tried to do server-side-rendered, streamed Flash games for years with limited success. The local machine in that case simply transmits input and displays video.
I think the difference here is that there will be some client side computation as well, but I'm not sure how much. If the GPU is in the cloud, that seems to indicate that they are bypassing WebGL, which would provide access to the local GPU. So my guess is that the JS does the typical setup work of a CPU in a rendering pipeline (setting up the scene, constructing draw batches), transmits it to the cloud GPU, and then transfers the rendered frame to the local GPU for display.
For interactive applications, it seems like the CPU-cloud GPU latency could be a deal breaker, though John Carmack famously said that it was faster to ping Europe from the US than to draw a pixel to the screen.
When it comes to watermarking, I'd like to see a cost comparison between watermarking and a static CDN (e.g. Netflix can serve 15+ Gbps per server).
Was posted here a few months back, it's a hand conversion of a mpeg decoder in JavaScript to stream ffmpeg via websockets to a canvas.
For the consumer it means you dont have to buy games, you can subscribe to a service and rent them. For the game developers, it means they don't have to worry about illegal copies.
I'd still like to see a demo page with their JavaScript decoder.
So, it's some client JS WebGL code, and something else driving the encoder in the cloud
I like the idea of scriptable VNC like streams.
You can read more about it here -> http://www.otoy.com/130501_OTOY_release_FINAL.pdf
sgi irix had something similar. think it was called inventor. basically a vmrl viwer plugin. also their last workstation was called octane.
This idea has been floating around for years. A company went bankrupt trying to do it.
I predict it won't happen unless/until Valve makes it happen. No one else would be able to convince enough gamers to switch. And Valve has no incentive to do it, because there's really no incentive for anyone to do it. At least, not for the gaming audience at large. This tech has the potential to be a godsend for 3D artists wishing for realtime previews of their work. But gamers? Not so much.
Remember the other day an article was floating around like "Desktop PCs aren't dead, we just don't need new ones"? That's finally starting to become true for gaming PCs as well. Gamers are quite content on their current gen boxes.
You may argue that this tech will enable higher graphics fidelity, and will blow people away with how real it looks. But considering nobody knows how to make games look any more real than they look now, I wouldn't hold my breath. Gaming graphics has plateaued.
In summary, "games rendered via the cloud" is the pets.com of the gaming industry.
EDIT: Oy. If you're going to try to refute me, then put some effort into it.
I pretty much agree with this. There may be cases outside of gaming that this will be useful though. It's funny how on the desktop market everyone wants to run everything in a browser and on the mobile everything is moving into an "app".
Gaikai is going to roll out with PS4 and only then we can judge how well is it doing. It's definitely solved the content issue so we can see if your technical angle holds.
Anyway, I'm not sure what point you are trying to make.
Yes, all remote display protocols are similar at some level.
The fact that this is programmable via Javascript and runs in the most widely deployed client app ever made (ie, a browser) is a fairly significant difference though.
I'm not aware of a way to do that easily using VNC.
Also, is there a good API for programming VNC? So I can inspect frames and act upon them?
On actual server hardware that "baseline latency" is about 5-10ms. So for any given client connecting to Gate One the response time for keystrokes should be at most 10ms + whatever the connection latency is.