WineD3D State management - going live(TM)

[Ivan Gyurdiev]

> device->addDirtyState(This, States[State]->representative)
>
> This way the code applying the states has to be called only once.
>   
What does addDirtyState() do when called multiple times with the same 
representative?

> This is still a bunch of code, not a magic instruction how to call gl 
> directly. To apply a state to gl
>
> States[State]->func(State, stateblock);
>   
How would I mark vertex shader constant #3653 dirty, and apply it using 
your mechanism ?
> I think you agree that the state grouping is a bit inflexible. For example, 
> the vertex declaration affects the fog settings. This way it would be 
> consequent to group them. However, as other things depend on the vertex decl 
> this will get a way to big group. The bigger the groups are the more likely 
> it is that one of the states is changed, so this will eat performance.
>   
I think you're mixing dirtification of states with mapping which 
function applies those states, and I don't fully understand how this is 
going to work yet...

> Sampler states and bound textures are more difficult, as they are per-texture 
> settings in gl and per device settings in d3d. 
That doesn't sound entirely correct - there are per-texture-unit 
settings in GL, and per-sampler settings in d3d. I thought we had to map 
the samplers to GL texture units.

 > There is no point in putting  them into the main state list, instead 
there should be a dirty list per supported sampler.

Again, it seems to me that two different concepts are being mixed 
together - I certainly don't want to be typing the function to apply per 
sampler, when there should be one entry in a table somewhere, with the 
sampler passed as an argument. Dirtification is another topic, which I 
don't think you can solve with a list anyway.
> I hope that explained the whole plan a bit better than my last mail :-)
>   
Sure, but I'm still confused :)