[10/10] WineD3D: Sort out some limit confusion

[Henri Verbeet]

2008/8/24 Stefan Dösinger <stefan at codeweavers.com>:
>> Ok, I wasn't sure. Wrt arbfp though, it should report 8 for
>> max_textures in that case, because that's how much simultaneous
>> textures d3d can address. max_textures, max_texture_stages, etc. are
>> the limits for what our d3d implementation can do, not GL.
> No, I don't think so. Even if we're using ARBfp, calling a glEnable(GL_TEXTURE_2D) in texture unit 5 is not valid on e.g. nvidia cards.
Sure, but there should be no reason to make that call either. In
pretty much every place GL_LIMITS(textures) is used, it would either
need to be replaced with the fragment pipe implementation based limit
or not be executed at all (eg. code that calls glTexEnvf or creates
dummy textures really doesn't need to be executed when using arbfp).
The only possible exception is SetupForBlit(), but I'm tempted to say
we shouldn't be using that either when shaders are available. It's a
pretty minor point though, and I'm not necessarily opposed to a
separate fragment pipe based limit.