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