I could really use a quick education (anyone offering).
Could someone tell me how we would fill a system with 2GB of usable ram (not vram). What I mean is I don't really understand what you guys are inferring too for binary data, I could assume that is basic code to tell the game how to run (compile textures x,y,z to model A etc etc) but I really don't know.
What is filling up the RAM today and what kind of scale would be present for the future? Master Chief/Drake - Would doubling the assets make an improvment in these characters, how would those assets increase etc etc.
How much room does a model take, does the size of the model increase at the same rate as the complexity (2x the amount of verticies = 2x the file size?)
Are we currently limited to the textures being used by the amount of ram available or is it more about processing speed. If it is ram what kind of textures are we looking at for next generation and size are they going to be?
Would the increase in processing power mean we would potentially have more objects on the screen? If so that would require textures too right?
I'm going on the presumption that the ram is being filled up with textures, audio, models, game code and.... ? that is where I'm getting stuck not knowing much about game design.
Thanks!
The very layman explanation would be analogy with zip packages and text documents. The documents compress to small size but must be decompressed before they can be used. This same applies to most game data(objects, textures, game logic, scripts and so on).
For textures GPU's use very specific kind of compression allowing easy and fast access to any pixel inside the compressed image. This GPU friendly compression is not as dense as formats like jpeg or jpeg2000 which don't allow user to access single pixels without decompressing larger blocks or even whole file.
What we could do here is to use these denser compressions on disc and then recompress on memory to GPU friendly format. The tradeoff is between io time and cpu cycles used to do the operation.
For vertex data displacement mapping could be viewed as an extreme compression method. Similarly heightmaps used to do terrains or voxels could be seen as rather extreme format of compression. If we start to have large models and lot's of vertex data even simple zip compression might give considerable savings. This gen vertex data is probably small enough not to warrant too much compression as there is not too much to be gained?
Similarly any data that is not compressed on disc or compressed unoptimally can benefit from compressing the asset on disc and re/decompression once transferred to memory.
Some data such as movies in disc already might use best possible practical compression and there is not much(if anything) to be gained without lowering quality.
AI might start by reading the control points for navigating and some basic decision trees from disc but then start dynamically building structures based on player actions and game engine feedback. This dynamic behavior will be done during runtime and eats more memory than what was actually read from the disc.
For rendering games use lot's of buffers to do calculation such as shadows, stereoscopic rendering, deferred shading, dynamic lightmaps/volumes, z-buffer, normal buffer and so on. All this data is generated on the run based on level geometry and not necessarily read from disc(prebaked content is an exception though). It's not a big jump to expect more advanced rendering next gen requiring more precision and more interim buffers. Also it might be that we will have higher AA or higher resolution rendering next gen eating into usable ram unless consoles continue to use xbox360 like edram solution and tiling that can use less memory than rendering everything in one go to main memory.
