Monday, January 17, 2011

Non-Power-Of-2 Texture Support

Just a few words on this. The differences are subtle but they do exist; a great example is the window in the Easy hall of the Start map. Unfortunately I haven't been able to get a screenshot that suitably demonstrates it (and JPG compression would wreck it anyway) so you'll just need to take my word for it.

The main one that you'll notice is that the stained glass lines are crisper and sharper, with no fuzziness. Colours also don't suffer from the "bleaching" that bilinear resampling causes.

Another advantage is that it saves some texture memory on account of not having to pad certain textures. This was necessary because the fuzziness I mentioned is a very noticeable artefact on 2D GUI textures in particular; compare the main menu image in an engine that supports padding with the same image in an engine that doesn't and you'll see what I mean.

Anyway, even though D3D does have better hardware capabilities checking than OpenGL, I've decided to err on the side of caution a little. Non-power-of-2 texture support is only going to be available on 3D cards that support Shader Model 3 and above (something that it seems impossible to check for in OpenGL... sigh). This means that the specific cards that caused problems in OpenGL (GeForce FX and certain ATIs from the same time) won't get them. I also create a texture and ensure that it's OK, just to be absolutely certain. This last was something I did in RMQ too, but OpenGL wasn't throwing any errors there either.

If you don't support non-power-of-2 textures you'll still go through the old paths, of course.

All in all, while it seems a shame to have to bring up the old OpenGL vs D3D thing again, this is definitely one area where D3D gives the programmer what he actually needs to properly implement a feature in a rational and predictable way.

0 comments: