WineD3D State management - going live(TM)

Ivan Gyurdiev ivg231 at
Mon Oct 23 01:43:29 CDT 2006

Stefan Dösinger wrote:
> Am Montag 23 Oktober 2006 00:57 schrieben Sie:
>> What does addDirtyState() do when called multiple times with the same
>> representative?
> There is a stateblock->changed.<somestate> field in the stateblock, which is a 
> boolean right now. This can be made a pointer to the list element, and set to 
> the element when the state is first add to the dirty list, and set to NULL 
> when the state is applied. When addDirtyState finds that a state already has 
> a list entry it doesn't have to dirtyfy it again
Ok, but that sounds rather messy...

>>> 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 ?
> Uhh, shader constants, must have forgotten them :-( . Well, Henri and I 
> silently agreed to leave them as they are right now. 
I don't like how the number of things staying "as they are right now" is 
growing, while the number of things being changed remains confined to 
render states. To have a proof-of-concept state management system, it 
would be best to take things that are as different as possible, and 
manage to get them successfully updated via the new state manager. 
Otherwise you won't find out whether the design is flawed or not until 
much later.

>>  > 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.
> No worries, we don't need a seperate function for each sampler :-) The apply 
> function gets a DWORD state value passed which it can use to find out to 
> which sampler to apply things and where to read the values from.
Yes, but it sounds like you need an entry for this function into the map 
for each sampler...
map { SAMPLER(0) -> sampler_apply_function }
map { SAMPLER(1) -> sampler_apply_function }
map { SAMPLER(2) ...

...and that seems wrong, but maybe I'm misunderstanding.

More information about the wine-devel mailing list