WineD3D State management - going live(TM)

Ivan Gyurdiev ivg231 at gmail.com
Sun Oct 22 03:07:13 CDT 2006


Jaap Stolk wrote:
> On 10/22/06, Ivan Gyurdiev <ivg231 at gmail.com> wrote:
>> > and we loose the ability to
>> > set up a constant table in the code.
>> The constant table is usually a bad idea, and this demonstrates why -
>
> I'm in favor of flexibility, but is it correct to assume that the
> number of functions that won't work very well with the table is small
> ?
> In that case we could put some special number in the table that
> indicates something like "look in the switch statement instead" for
> those functions. This way we keep the flexibility, keep the switch
> statement small and keep the standard functions optimized.
I shouldn't have mentioned a switch statement, that was to illustrate an 
example.

My concern with this particular table is that at the moment it seems too 
narrow, targeted at render states [ and discussion shows adding sampler 
states isn't as straightforward as it seems. ]. I imagine a constant map 
from keys [ APPLY_SAMPLERS, APPLY_ZENABLE, ... ] to function pointers. 
I'm not quite sure why we're looking into adding pointers per sampler - 
doesn't really make sense to me. There's three things involved here: (1) 
how to store the D3D data, (2) how to store the GL data, and (3) how to 
apply the GL data. Discussion of anything "per-sampler" has to pertain 
to (1) or (2), but really has nothing to do with (3)... 

For storing the D3D data, a different type of structure is necessary, I 
like Henri's tree ideas, maybe they can be used to enhance the current 
stateblock. That structure would be passed as an argument to the 
functions that the above table points to. A list of dirty states could 
specify which "apply" functions to execute, but you still need to pass 
in data to those functions, and the sampler number seems like it should 
be part of the data, not part of how things are indexed. To apply 
changes to sampler#6 you'd call the APPLY_SAMPLERS function, with a data 
arg that marks the 6th sampler dirty, and contains data for sampler 6.









More information about the wine-devel mailing list