On 29 January 2010 00:27, Stefan Dösinger <[email protected]> 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.
