On 29 January 2010 00:27, Stefan Dösinger stefandoesinger@gmx.at wrote:
Please use the number of texture blend stages reported from the fragment pipeline rather than gl_limits.texture_stages. texture_stages only works with the nvrc and ffp pipelines, but not arbfp or atifs(it works out ok by chance on most GL cards).
If those aren't the same, the code initializing the texture_stages limit is broken, not the code using it.
There's a deeper issue with how we manage texture limits, because currently the extension loading code picks limits.texture_stages, already anticipating which pipeline we'll choose later. We should handle this in the way shader
True, but that code was there before the concept of a fragment pipeline was introduced in wined3d.
constants are handled: Rename limits.texture_stages to limits.max_nv_general_combiners, make only the nvrc and nvts pipelines read this extension specific value, and use the pipeline reported d3d texture blend stages in fragment pipeline independent code. We're also (still) mixing up blend stages with fixed function vertex coordinates.
Almost. The texture_stages limit is supposed to indicate the number of texture stages the GL implementation can support, I don't think there's a reason to change that. What needs to change is that we assign its value based on the fragment pipeline caps instead of based on the GL extensions.