> 2008/8/22 Stefan Dösinger <[EMAIL PROTECTED]>:
> > + glGetIntegerv(GL_MAX_TEXTURE_COORDS, &gl_max);
> > + gl_info->max_texture_coords = min(MAX_TEXTURES, gl_max);
> > + TRACE_(d3d_caps)("Max texture coords: %d\n", gl_info-
> >max_texture_coords);
> I don't know if this is intentional or not, but did you mean to use
> gl_info->max_textures here?
No, I meant to clamp it by the constant MAX_TEXTURES(=8). gl_info->max_textures
is wrong here because gl_info->max_textures could be 4, GL_MAX_TEXTURE_COORDS
could be 8. If the application uses fixed function vertex processing and pixel
shaders it can make use of all 8 texture coords in the vertex pipeline even
though the fixed function fragment pipeline supports only 4 textures. Or we
could use the arbfp code which isn't limited by gl_info->max_textures.
> > @@ -3172,7 +3172,7 @@ static void
> loadTexCoords(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertex
> > return;
> > }
> >
> > - for (textureNo = 0; textureNo < GL_LIMITS(texture_stages);
> ++textureNo) {
> > + for (textureNo = 0; textureNo < GL_LIMITS(texture_coords);
> ++textureNo) {
> > int coordIdx = stateblock-
> >textureState[textureNo][WINED3DTSS_TEXCOORDINDEX];
> >
> > mapped_stage = stateblock->wineD3DDevice-
> >texUnitMap[textureNo];
> Shouldn't that be testing mapped_stage against
> GL_LIMITS(texture_coords) instead?
You mean instead of textureNo? I don't think so. A stage is always mapped to a
lower one, so I think we cannot trigger an error here. Dealing with all
supported texture units here spares the loop below.
> > - if (GL_SUPPORT(NV_REGISTER_COMBINERS)) {
> > - /* The number of the mapped stages increases monotonically,
> so it's fine to use the last used one */
> > - for (textureNo = mapped_stage + 1; textureNo <
> GL_LIMITS(textures); ++textureNo) {
> > - GL_EXTCALL(glMultiTexCoord4fARB(GL_TEXTURE0_ARB +
> textureNo, 0, 0, 0, 1));
> > - }
> > - }
> I'm probably missing something here, but why is it safe to remove that?
Because we have handled all supported texture units in the loop above. and
supplied it with default coordinates if needed.
> In the bigger picture, these various limits are pretty tricky to get
> right, I wonder if it might make more sense to handle most of this
> stuff in the tex unit map instead. That way we could be sure that if a
> stage is mapped to a sampler that sampler is safe to use.
While this sounds nice I am afraid it won't work too well. Beyond specifying
the new settings we have to do other things like unsetting unneeded states,
etc, so I don't think we can keep the state mappings all in one place. My other
concern is that different pipeline implementations need different limits.
