Mifely said:
Textures, sound, and animation (a lot of the things that can be made lower-quality easily) are usually compressed as well. 120MB of textures is a lot more texture data than 30M 32-bit RGBA values, in other words. My numbers are pretty close -- The textures might take up some additional memory (like part of the 60 extra megs I mentioned), but not as much as you might think. I should add that, if the texture/animation/sound data is compressed, it requires some CPU horsepower to decompress and utilize each frame... another gotcha for the Wii, relative to the PS3/360 -- in order to process the data fast enough the Wii not only needs the data to be smaller, but in some cases might require less efficient compression than the more powerful consoles. The Wii will always have great exclusives. It will never share games experiences with the other consoles, but that doesn't mean it won't have great games -- obviously it does. Downporting to it is kinda pointless, in that its so difficult, that developers are always better off making a game focused solely on the Wii's strengths, instead of trying to shove a game that uses the "big" consoles' strengths onto the Wii.
|
Honestly, if the actuall code and global data when loaded into memory takes up more than (about) 8MB you're a crappy developer or using an inappropriate language for developing a game ...
Most memory usage in a videogame is made up of 3D objects, their associated textures, as well as sound, music and video files; all of which would be (greatly) reduced in size if you're targeting a videogame with the graphical and sound capabilities of the Wii. Skeletal animation takes up a bit of memory, but its growth in memory usage has not grown as dramatically as geometry or textures since its initial introduction in the late 90s; AI memory usage is tiny being that it is (typically) made up of a set of small textfiles that are for scripting, physics is also takes up a tiny ammount of memory being that you're creating a collision detection frame and associating a couple of parameters to it, and navigational points are (typically) represented as a vertex that is attached to other navigation points with a set of edges and I would question any developer who used more than 128k on a level in path-finding data.







