Boggy B: You said it isn't possible to compress a 1MB texture to 500k without loss.
This is a 1MB (512x512 32bit TGA) texture from one of my Quake 3 playermodels. I agree, I'm no good at skinning, but that's not the point. The point is, this is a 230 kilobyte PNG file. PNG is a lossless compression. That's less than 25% of the original size without any loss in quality. Of course, in most situations you have a noise layer added to the texture (zoom in on the Yoshi and Yoshi-SMASH- trophies in SSBM for an example) which doesn't compress well in PNG. But you can apply loss-compression (like DXT) to such a texture without sacrificing quality (after all, the texture already has a lot of random junk and there's no difference between random junk and compressed random junk). Better texture compression doesn't mean more loss, but less loss at same size (compare MP3 and OGG).
A noticeable effect on GC is the amount of distortion (not bad UV mapping, the effect!) going on. In SMS, the water (both level water and your fludd's beam) distorts what's behind it, MP uses heat distortion and the charge beam does some, PSO does it noticeable on telepipes and less noticeable on water (Cave 2, look at your feet, if you don't believe me!). Heat distortion is used in MANY GC games (and I bet the focus thing in WW uses the same effect). I've never played XB, does it use the same amount of distortion? PSO for XB certainly doesn't...
A thing to be considered: There's no difference whether 15mps are displayed at 60 or 30FPS, the latter just means the 15 million triangles are distributed over 30 frames instead of 60.
Also I'm not sure the XB doesn't do bumpmapping via it's shaders, as most shader cards use them for all the effects older cards could do via unprogrammable hardware (e.g. alpha transparency).
The MIPS (which BTW count different depending on the instructions known by the processor, where x86s generally suck) might be important for physics as well, but the FLOPS are critical here. See, a physics model works with floating points only and all transformations used here are floating point operations. FLOPs are what set AMD apart of Intel and where Intel traditionally lacked. You know why there was a separate math processor available for the 3x86? Because the x86 is incredibly bad at floating point operations. That point has bettered over the years, still Intel has a weakness in the FLOPS area.
I'm not sure about the importance of cubic envmaps for reflections, as you have to render the envmap for the reflection as well and this eats performance. Usually envmaps are static, with the scenery of the level prerendered into them. Serious Sam, for example, can convert a cube envmap into a spheric envmap which can be used with less advanced graphics cards.
Another point I'd like to address is the difference etween a normalmap and a bumpmap. Doom 3, Deus Ex 2 and Quake 1 Tenebrae use normalmaps, which, unlike bumpmaps, store normal orientation instead of some "height". Normalmapping is used when a highpoly model is converted to a "texture" for a lowpoly one (Doom 3 pushes up to 5000 polies per model). Bumpmaps (e.g. Halo 2) usually are hand drawn greyscale images which store the height of the texels, which lighting is then calculated from. Bumpmaps can be used in hardware displacement mapping (DX9 and higher) because they contain absolute positions for the pixels, instead of relative orientations like normalmaps do. Halo 2 style bumpmapping could be done on the GC as well, but I'm not sure about Doom 3 style normalmapping. But whether shader or not, Normalmapping is a serious impact on performance (play Tenebrae!) and very time consuming to use for models (you need two models each, most companies won't risk the aditional cost this causes).
Hm, hope I forgot nothing in this post...
Show Posts
