- Does not scale to more complex support checks. I suspect you'll have
to have to rewrite this as soon as a case comes up that requires more than a single support check to establish support. A function pointer may help here. It would also be interesting to look at similarities and differences with the ffp pipeline replacement - which is essentially the same thing on a much larger scale, where multiple states are replaced rather than a single state. Can these support checks handle the case where an extension would control replacing a group of states ?
A function pointer is a nice idea actually. I don't think we'll ever need more than one extension per state line though, and the current scheme can happily deal with two optional extensions(as a later patch dealing with conditional NP2 textures will do). I don't expect that any new function will come around that needs two extension checks at the same time since the fixed function pipeline in both gl and d3d is in its final state and no new features will come up, and shaders are well-standardized.
IMO the current way is easier to read, and until we need a more flexible solution I'd pledge to keep the current code, since no matter what we(I) would have to rewrite it. It is a pain to rewrite/modify a set of patches so I don't want to do it unless we're certain we'll need it
- Not necessarily relating to this patch, but in general I would be
wary of trying to replace every if check with a pointer. Splitting on extension support is probably ok.
It is a performance consideration. The point of doing this is to coalesce if checks into a function pointer abstraction layer that exists anyway. Those if checks can be evaluated at device creation time, so there's no need to run through them every time the state is applied.
The bigger picture is that we have 3 function pointer abstraction layers we can't get rid of: The vtables(we really want inheritance), the state table and the shader backend. My idea is to merge as many if checks as possible that can be determined at object creation time into these anyway-existant abstraction layers. (Of course with the vtables that's a bit ugly, unless we generate vtables dynamically)