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)