I'm thinking of removing support for 16bpp modes. There are a few reasons for this, so let's go through them:
- Unlike OpenGL, which gives you a 32bpp backbuffer but dithers it down to 16bpp for display, with D3D when you create a 16bpp mode you get a 16bpp backbuffer. I suspect that this may be a potential root cause of some folks having observed certain quality loss issues with textures in DirectQ.
- The performance advantages on older hardware of running in a 16bpp mode are dubious at best with modern (at least D3D9-class) hardware. At worst it may actually run slower as it has to translate textures and blending results from 32bpp to 16bpp (this has been observed - switching from 16bpp to 32bpp gave an over 2.5x framerate increase for one person). I suspect that some people may even be deliberately selecting 16bpp modes out of habit from GLQuake and not be even aware that they're getting nowhere near the best out of DirectQ.
- Availability of 32bpp modes is not an issue. Since DirectQ needs D3D9-class hardware anyway, if you're able to run your desktop at 1280x1024x32bpp then you've got a 32bpp mode of the same resolution available. This is guaranteed. The other major advantage of having 16bpp modes - as a fallback if the equivalent 32bpp mode is unavailable - is no longer relevant.
- In addition to the above, removing 16bpp modes simplifies the startup and video mode selection code, making it more robust.
Update - too late! The deed is done.
2 comments:
You'll get no complaints from me. I got my first taste of 32-bit color back in 1998 (or thereabouts) and haven't looked back since.
Another bit of old, legacy garbage removed; good job!
Post a Comment