Am 02.01.2007 um 05:38 schrieb Ivan Gyurdiev:
+ if (stateblock->wineD3DDevice->vs_selected_mode != SHADER_NONE
&& stateblock->vertexShader && + ((IWineD3DVertexShaderImpl *)
stateblock->vertexShader)->baseShader.function != NULL)
+ memcpy(&stateblock->wineD3DDevice->strided_streams,
stateblock->wineD3DDevice->up_strided, sizeof(stateblock-
>wineD3DDevice->strided_streams));
+ primitiveDeclarationConvertToStridedData
((IWineD3DDevice *) stateblock->wineD3DDevice,
useVertexShaderFunction, + &stateblock-
>wineD3DDevice->strided_streams, &stateblock->wineD3DDevice-
>streamFixedUp);
My eyes hurt - can we *please* store the device in a local variable.
Ok, I can change that :-)
Also, I am not sure how we got to the point where this many upward
references to the device from the stateblock are necessary - there
has to be something wrong with that: a stateblock captures the
state of a device, so why is it referring back to its parent device
and looking up state there? This type of thing was introduced into
the shader code as well, and IIRC it was wrong there too.
I knew you'd come up with that :-) . My plan is to remove all the
upward references to the device later on and store most of the things
stored in the device in a seperate context variable, which is passed
to the state handlers. But for now I want to keep the code unchanged
as much as possible, and thus work with the device everywhere.
Also, all this transient data from the drawprim codepath moved into
the device - can you explain again why that's necessary, does it
really need to persist after the drawprim call?
Yes, most of the data stays valid and can be used after the drawprim
finished. The decoded vertex declaration is valid until the next
SetStreamSource, SetVertexDeclaration, SetFVF or SetVertexShader
call. Future drawprim calls can reuse it, and the Vertex Buffer
Preload function can access it too(instead having to do its own
decoding to get exactly the same result)
