OnLive

[Izuno]

When consoles have multi-terabyte solid state hard drives that run at higher speeds, more reliability and cooler, one of the bottlenecks in digital distribution (again, on consoles) will be solved. I feel like this will happen before gaming-on-demand technology can fully deliver on shooters etc. In other words It's just a matter of time on widespread console digital distribution, though OnLine/Gaikai/Otoy etc. will be a longer time coming. Hmmm...hasn't everyone been thinking this anyway?

I'm curious what kind of presence OnLive will have at GDC in March considering that last year it was a bit of a coming out party for them.

[Duff-e]

The whole idea is something everyone has thought of at least once. I'm sure all the major publishers have enough money to create a working digital distribution network tomorrow if they felt like it. Resources, not innovation, are holding the idea back. Innovative solutions would be things like facebook vs myspace, google maps vs mapquest. For example say it's 1991 and you're using the world wide web for the first time. Who doesn't think, "holy shit, I can buy and sell things on the internet now." The problem is without something like SSL you pretty much have to say a prayer before you put in your credit card information, it doesn't matter how well known or fancy the website you're buying from is.

When I talk with friends about ideas almost all of them fall into the latter description. With 20 minutes of brainstorming anyone could come up with ideas that would change the world...most of these fail because they require the ability to influence the infrastructure of the world.

[Sentura]

I don't see how it can. The whole point of this is that it is rendering the game for you. Therefore it needs to react to your input, render the results of your input, then send it back. You can't just have a buffer to deal with that because what are you going to buffer? The rendered video that has resulted from an input you haven't even made yet?

well obviously if you're going to buffer something here, you're going to buffer a core I/O package, the basics for the engine as well as a number of levels. this may be the entire game, but it doesn't have to be. when i said that the thing had a buffer, however, i was referring to entire games being buffered at a time.

[Sentura]

I don't see how it can. The whole point of this is that it is rendering the game for you. Therefore it needs to react to your input, render the results of your input, then send it back. You can't just have a buffer to deal with that because what are you going to buffer? The rendered video that has resulted from an input you haven't even made yet?

well obviously if you're going to buffer something here, you're going to buffer a core I/O package, the basics for the engine as well as a number of levels. this may be the entire game, but it doesn't have to be. when i said that the thing had a buffer, however, i was referring to entire games being buffered at a time.

as an addendum it could be that they are creating their own protocol for data transfer, which could account for some parts of a high speed transfer. i'm not saying it's a silver bullet, but a few small creeks still go together to create a river.

[Skjalg]

They havent, he said they use UDP.

[Sentura]

They havent, he said they use UDP.

bwahhahahahaa

[Skjalg]

They havent, he said they use UDP.

bwahhahahahaa

Why are you laughing? Did you expect them to optimize something that cant be optimized? If you didn't know, UDP just spews out packets in one direction, not caring if they get there or not. Which is basically excellent for video and audio because if a frame gets lost here and there we wouldn't notice. Theres basically no way they can improve on that simple set of logic.

I'm surprised you'd think so with a programmers education.

[Sentura]

They havent, he said they use UDP.

bwahhahahahaa

Why are you laughing? Did you expect them to optimize something that cant be optimized? If you didn't know, UDP just spews out packets in one direction, not caring if they get there or not. Which is basically excellent for video and audio because if a frame gets lost here and there we wouldn't notice. Theres basically no way they can improve on that simple set of logic.

I'm surprised you'd think so with a programmers education.

well i'm glad you're already accusing me of not knowing what i'm talking about on the base of your own assumptions, but let me explain:

if we're talking A/V, then i'd have no problem using UDP. however, if we're talking games (where arguably every action the player takes is important, and every action needs to connect to the server), you cannot use UDP because of the packet loss. if their whole premise is to revolutionize the way games will be played using UDP, then excuse me while i laugh some more.

[Skjalg]

Obviously, they are using UDP for the video feed, and I'm perry sure that was what he was referring to when he answered.

They might be using something else for the user input, still no need for making their own protocol when the handshake in tcp/ip is sufficent.

if their whole premise is to revolutionize the way games will be played using UDP, then excuse me while i laugh some more.

Dont say you know what you're talking about, then post something like this that only shows that you still think you can make something better than UDP (Udp light) for one way transfer of a video feed. And as far as I know, they have always said that they have not revoloutionized how to play games, just how to decode a video feed for so its smaller and easier to transfer via regular protocols. Why they are targetting it for games first is a little weird and what is the most baffling to me. (Why not use this shit for everything?, why only for games?)

[Sentura]

the point of creating a new protocol would be to tailor it to the exact needs of the OnLive system. there are pros and cons associated with every data structure and every protocol. you choose them on how they are best used. i highly doubt that a UDP connection is worth it for games (and yes, we're discussing games here, not just A/V). while TCP would be a standard choice for transferring game data my own reasoning came from that there for this system should be a better way of transferring data rather than using TCP since the circumstances are so specific for this system.

also, i never ever said i was talking about video feeds. excuse me if i missed something (you just said they use UDP, not that they use UDP for video feed), but i was only talking about games.

[Skjalg]

Since the majority (like 99.999999999999999%) of the data that is transmitted, and the data that really has been the bottleneck thus far for such a product is the video feed, I merely made the quite logical step of believing you were thinking of the same thing as I.

If you think that transferring key press events is what would be the bottle neck or the hard-to-accomplish piece of this puzzle, then you're in for a big surprise. I mean you can literally fit that into a single tcp/ip packet.

And UDP really is worth it for games, it wouldn't even surprise me if its the number #1 protocol for games. I remember playing StarCraft over IPX, then rejoicing when they added support for both TCP/IP and UDP. (its not a type of connection, its a protocol, a protocol is more about how your packet is made up than how it is transferred). Even by reading like half a page on wikipedia you'd learn why you are coming off as someone that is digging himself deeper and deeper into explaining things away that make no sense.

I'd be more inclined to laugh with you if you were complaining about the impossibility of making something that decodes/encodes movies/video feed as quickly as he states, instead of laughing at you for thinking that its all about the protocol.

[Sentura]

Since the majority (like 99.999999999999999%) of the data that is transmitted, and the data that really has been the bottleneck thus far for such a product is the video feed, I merely made the quite logical step of believing you were thinking of the same thing as I.

If you think that transferring key press events is what would be the bottle neck or the hard-to-accomplish piece of this puzzle, then you're in for a big surprise. I mean you can literally fit that into a single tcp/ip packet.

And UDP really is worth it for games, it wouldn't even surprise me if its the number #1 protocol for games. I remember playing StarCraft over IPX, then rejoicing when they added support for both TCP/IP and UDP. (its not a type of connection, its a protocol, a protocol is more about how your packet is made up than how it is transferred). Even by reading like half a page on wikipedia you'd learn why you are coming off as someone that is digging himself deeper and deeper into explaining things away that make no sense.

I'd be more inclined to laugh with you if you were complaining about the impossibility of making something that decodes/encodes movies/video feed as quickly as he states, instead of laughing at you for thinking that its all about the protocol.

what i'm saying is that not every packet reaches its destination with udp. i never discussed the contents of a packet in more detail than that, because data loss alone in a system that requires input to go necessarily go through. not having data reliability would maybe not so much be a bottleneck, but just a major inconvenience. the sense in creating a new protocol would be that you could perhaps limit the overhead you have on tcp to just the bare minimum, while still having data reliability. not in the sense of the video feed you suggested, however, but in the sense that you buffered the entire game locally.

i don't see how you logically connect the video feed with a game either, but that seems attributed to you looking at a different architecture than the one i was discussing? and again, the reason for the laughs was the packet loss that udp causes. if you have no guarantee for the reception of input data, it would be a tedious process to play a game.

[zaphod]

most multiplayer games use UDP

[Defrag]

The important thing is that you can build a reliability mechanism on top of UDP so that only certain messages are treated as important whereas the others can be discarded without much of a problem. I.e. the protocol doesn't guarantee delivery, but the application code adds in that support. It's a bit more work, but a fairly common thing to see in games.

[Sentura]

The important thing is that you can build a reliability mechanism on top of UDP so that only certain messages are treated as important whereas the others can be discarded without much of a problem. I.e. the protocol doesn't guarantee delivery, but the application code adds in that support. It's a bit more work, but a fairly common thing to see in games.

this is what i was trying to argue as well. thank you.