Benchmark for Bright Textures (i.e. Mizzy's Thread)

[D-Scythe]

Well, ran a detailed benchmark of Bright Textures. Converted a preliminary batch, including virtually every city/airfield BMP texture, into 256 colour and tested it using the first 2 minutes of ED's column hunt track.

 

Here are the results:

 

Blue is normal, Purple is Bright.

 

There is a little increase in average FPS, but not much. Here is the FRAPs log for the two data sets:

 

Normal:

Frames: 2116 - Time: 118280ms - Avg: 17.890 - Min: 0 - Max: 43

Bright:

Frames: 2224 - Time: 120355ms - Avg: 18.479 - Min: 0 - Max: 43

 

The difference is about 0.6 FPS; it's nothing to write home about. Don't think it is worth converting every single texture with Bright, unless you got time on your hands.

[Jammer]

No surprise -- even though the "Bright" textures are 8-bit on disk, they are eventually converted to 8 bits per channel (24/32 total bits per texel) once uploaded to video memory. The only benefit these might give you is faster load times, and perhaps a little less stutter.

 

On the other hand, converting all textures to a compressed DXTn DDS format (DXT1 for opaque textures, 1a for binary alpha, 3 for low-quality alpha, or 5 for high-quality alpha) would instead provide much reduced system and video memory usage, since they would remain compressed throughout the pipeline (HD -> system memory -> video memory), and a potentially significant FPS boost on some hardware. Believe it or not, but a compressed DXTn DDS texture consumes less video memory than one of these 8-bit "Bright" textures.

[Pilotasso]

This benchmark is wrong. LOMAN re-converted everything back to 16 bit in packing the CDDS. Check page 10 of Mizzy's thread:

 

http://forum.lockon.ru/showthread.php?t=12297&page=10