so your saying that when Sony made their Cloud Processing aannoucement during the PS4 conference it was NOTHING but Damage Control and PR BullShit?

Sony didn't talk about cloud processing. They talked about cloud gaming.  Which isn't the same thing, believe it or not.

Sony said something about Gaikai and cloud gaming, I heard nothing about "cloud processing".  And if they DID say something about it, yea, its a buzzword and PR bullshit.  No damage control though, they didnt need it.

If you think for once second, I back any company over another, you are sorely mistaken. PR crap is crap. No matter who spews it out. So take that role reversal spin shit somewhere else, because I wont bother responding anymore.

Thanks, I didnt see that before I replied.

https://www.youtube.com/watch?v=qh8KLN-l86o

Start from 29:40...And if you feel that becuase he says Cloud Technology instead of processing...then you win

To be honest, who cares if the whole thread believes one way.  It would be different if the whole thread was compose of developers and they were giving their feedback on what they have experience but its not.  Also people seem to be getting confused about the two concepts between Gaikia and Cloud compute.  

When I think about cloud compute, I think about an Application Server or Database.  The game code just sends API calls to the App Server or if its a database you just execute a stored procedure.  The amount of information sent along the wire is very small and can be compressed if need be because the Xi have dedicated hardware for encoding and decoding.  The information can be sent back compressed, and cache in local memory to be fetch by the CPU or GPU.  One of the things that was leaked about the X1 APU is that it can process compressed data directly.  An enterprising developer probably could host a lot of jobs on the cloud platform and just call those jobs just like calling a stored procedure.  The data could be sent way before the player get to those parts letting the local APU concentrate on immediate situations.

~

Edit: Quote tree shortened by TruckOSaurus - Please refer to this post for Quote Tree Guidelines http://gamrconnect.vgchartz.com/post.php?id=5379187 

Processing compressed data is nothing new though. I was doing it in '96 out of pure necessity, gpu's have been doing it for a decade with compressed textures. It's nice that is has dedicated compression and decompression but the usefulness of a standard compression method for game data is very limited. Within the company I worked for: if zip can make a significant dent on your database, then you're doing it wrong, start optimizing. We rendered and computed directly from compressed data that zip could not get more then 1% of 'air' out of. And compressed at a minimum of 5x better then using a standard compression method on the original data.

It's a trade off. Everything you download and store ahead takes away from available memory for immediate tasks. I've also run into plenty of situations where it was better to do just in time calculations instead of sacrificing memory and bandwidth by pre-storing data.

Plus the server needs to be ready with an instanced copy of your game in memory with where you are. Pretty much running in parallel with what you are doing. To make that efficient (and not run a second game for everyone playing) it will require a lot of resources to make the server side part efficient. Unfortunately it's not so simple as making a few api calls and getting a bit of data back.

it's interesting but a lot more complicated then folding@home and seti search type distributed computing.
Next gen's mmorpg are going to be amazing though :) (I hope)

Having everything compressed keeps it effecient.  No wasted time encoding and decoding thus improving performace.  As everything has a cost, depending on how many jobs are being processed and sent over the wire, the nano seconds in encoding decoding can mean a lot if you have 100s of jobs being processed.

I do not see how memory will be an issue with 8GB.  Even if the OS takes 2 to 3 still gives a lot of memory for use.  If the data is compressed it also helps to keep memory available.  Non immediate stuff can be temporarly stored on the HDD.  When I write web applications, I am always prefetching information from databases and caching them before users actually select and object which will be used.  SImple things like Google Autocomplete is one such thing that I use when creating dynamic Eforms for line of business scenerios.  For some queries hitting databases, it could take some time to filter through information so its always best to work with a local cache to improve performance.

As to your point about having an instance copy ready, you should take a look at MS Orleans Platform.  Here is a link from MS Research.  http://research.microsoft.com/en-us/projects/orleans/

MS stated that for each X1 sold, developers will have the capability to leaverage 3 X1 compute power in the cloud.  Basically this means that Developers will have a persistance instance of their code available to leaverage for cloud compute.  The Orleans is one project that is created to provide that type of distributed, persistance resource which was in development since 2008.  Read the part from the Programming model and the grains concept to see how MS has built a platform to solve that solution.  Current the Halo team is using the platform so we might actually see real world product using the cloud compute from them.

You are right that this type of setup is extreamly complex and not something that was thought up in a few months because of Sony reveal.  On a geek from I am very interested to see how this technology will play out and if it actually will be the next coming as MS is prone to hype.

I wasn't arguing the usefullness of working with compressed data, but the particular use of standardized compression tools as proposed in the move engines. It makes sense for web applications, http requests and responses, form data, etc are terribly wasteful in memory size. It is a lot less useful for binary game data though, especially with properly optimized (or already compressed) data structures.

It's the same vibe I get from the New Orleans platform. An abstract layer build for easily scaleable business web applications. Applying it to games, especially single player games seems a bit of an extra money grab. As if someone came up with an idea to make more money of the Azure platform by offering it to enhance games. Charge developers to use the web hosting, charge players the live gold fee for enhanced single player.

From a game development standpoint it's great to have to have access to an already established widely distributed server network. But the grains themselves still need to be build from the ground up. Developing a fully fledged server side version of the game (which probably can't rely on specific hardware and needs to be ported to the available apis) is a huge undertaking for a couple of enhancements.

8gb ram seems like a lot now (or 5 or 7 whatever is left after the OS) but so was 512mb in 2004 after the ps2 with only 32+4mb available. Yet it didn't take long before developers ran out of memory again. (Remember Bill Gates' famous quote in '81 640kb should keep everyone happy for the next 10 years...)
In my experience ram is always the bottleneck, together with read/write speed. Working directly with bitstream compressed optimized data and letting the processor do some extra work is preferable to sacrificing memory and bandwidth to pre storing too many things.  I don't see it being very practical for preparing light maps or complex animation sequences. More useful for mmo type settings where you offload memory and caching by letting the server keep track of the world and send you the relevant cell data when needed. Yet that's not applicable to single player games that need to keep working when the connection drops.

The first games won't have any memory problems ofcourse, they won't max out the 8 processor cores either. So I wonder what (if anything) they'll show at E3 for cloud computing enhancements in single player games, and whether that couldn't be done locally with a bit of optimizing.

heres i