By using this site, you agree to our Privacy Policy and our Terms of Use. Close
Mifely said:
Just_Ben said:
Mifely said:

Do all Wii owners imagine that they purchased a console that will, someday, be able to play all the HD console games, merely with a minor loss in texture quality? Textures take a fair chunk of memory, yes, but... its hardly the sole contributor to the memory footprint of an application like GTA4 or AC. Lemme throw up a sample memory budget for a run-of-the-mill HD game:

* 30-60 MB -- OS (I think the Wii has a much smaller OS)
* 4 MB -- screen buffers (easy to shrink if you lose HD)
* 60 MB -- code and global data (next to impossible to shrink without changing the game)
* 30 MB -- game objects (next to impossible to shrink -- see above)
* 20 MB -- animations (easy to shrink... but with substantial quality loss)
* 60 MB -- physics/collision data (pretty hard to shrink without serious level changes, which means you're re-doing all the content)
* 120 MB -- textures (easy to shrink, acceptable quality loss, IMO)
* 60 MB -- visual geometry (kinda hard to shrink, but somewhat doable, depending on artist skills and tools... and time)
* 20 MB -- sound (easy to shrink if you lower quality and compress like crazy... maybe)
* 20 MB -- AI navigational data (pretty dang hard to shrink without really messing up the AI and re-doing the content)
* ~60 MB -- misc crap I forgot (most stuff is usually much harder to shrink than textures)

Now fit that on the 64+27MB of the Wii, after accounting for, I would hope, 8MB or less for the Wii's OS. You come out with a completely different game, that is also lame compared to its HD counterpart(s).

And yes, HD cross-platform games ALWAYS use ALL the memory available. I don't think I've ever heard of a HD game that didn't have to squeeze into its platform(s) memory budget at some point in its development cycle. This has been true for... eons. Consoles never have as much memory as the developers want.

I am no game developer, but at least a developer, and this numbers look awfull wrong to me. 60 MB code, compiled, in the ram? Only 120 MB for the textures? Thats not much. Sorry but I think all things you mentioned are way to high and the textures are way to low.

 

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.