Jaap Stolk wrote:
On 10/22/06, Ivan Gyurdiev ivg231@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.