Re: wined3d: print real unhandled D3DCMPFUNC value

[Jan Zerebecki]

On Sun, Aug 20, 2006 at 01:37:04PM -0700, Chris Robinson wrote:
> --- dlls/wined3d/device.c	10 Aug 2006 09:43:54 -0000	1.275
> +++ dlls/wined3d/device.c	20 Aug 2006 20:31:10 -0000
> @@ -3666,7 +3666,7 @@
>                  case D3DCMP_GREATEREQUAL:  glParm = GL_GEQUAL; break;
>                  case D3DCMP_ALWAYS:        glParm = GL_ALWAYS; break;
>                  default:
> -
>                FIXME("Unrecognized/Unhandled D3DCMPFUNC value %ld\n", Value);
> -
>                FIXME("Unrecognized/Unhandled D3DCMPFUNC value %ld\n", This->stateBlock->renderState[WINED3DRS_ALPHAFUNC]);

(I forgot if I verified this, but) I think that when a state is
beeing set This->stateBlock->renderState[State] has the previous
value and only Value has the one to be set. From a quick glance
it seems the code for this renderstate (and maybe more
renderstates) wrongly assumes the contrary.

Jan

wined3d: print real unhandled D3DCMPFUNC value

[Chris Robinson]

On Sunday 20 August 2006 18:36, you wrote:
> (I forgot if I verified this, but) I think that when a state is
> beeing set This->stateBlock->renderState[State] has the previous
> value and only Value has the one to be set. From a quick glance
> it seems the code for this renderstate (and maybe more
> renderstates) wrongly assumes the contrary.

The top of the function has:
This->updateStateBlock->renderState[State] = Value;
before entering the main switch.

The problem with relying on Value is, that code block can be entered when 
State is WINED3DRS_ALPHATESTENABLE, WINED3DRS_ALPHAFUNC, WINED3DRS_ALPHAREF, 
or WINED3DRS_COLORKEYENABLE. And if it's not WINED3DRS_ALPHAFUNC, then Value 
isn't the same as This->stateBlock->renderState[WINED3DRS_ALPHAFUNC]. which 
would cause the wrong value to be reported.

Without this patch, Morrowind reports that 1 and 8 are unrecognized D3DCMPFUNC 
values, which is odd since they are recognized and handled properly. It turns 
out that 1 and 8 are being set for D3DRS_ALPHATESTENABLE and D3DRS_ALPHAREF 
respectively, and the unrecognized D3DCMPFUNC value is actually 0 (this was 
verified via trace+d3d). With the patch, Wine properly reports that 0 is the 
unrecognized D3DCMPFUNC value (which the game seems to set temporarilly for 
some reason).

wined3d: print real unhandled D3DCMPFUNC value

[H. Verbeet]

On 21/08/06, Jan Zerebecki  wrote:
> (I forgot if I verified this, but) I think that when a state is
> beeing set This->stateBlock->renderState[State] has the previous
> value and only Value has the one to be set. From a quick glance
> it seems the code for this renderstate (and maybe more
> renderstates) wrongly assumes the contrary.

Normally, yes. This->stateBlock is the state currently set, and
This->updateStateblock contains the new state. In case we're
recording, those are two different stateblocks. However, at the start
of SetRenderState:

if (This->isRecordingState) {
        TRACE("Recording... not performing anything\n");
        return WINED3D_OK;
}

That guarantees that in the code below stateBlock and updateStateblock
point to the same stateblock.