Question about 'EffectParameter' class

Ultrahead

Given that the EffectParameter class is sealed I need to ask: any chance for future versions to take advantage of generics for methods like SetValue and GetValue

I 'm not meaning to create a new 'EffectParameter<T>' class (what'd make it difficult for the 'EffectParameterCollection' class), but something like:

• GetValue<T>() or GetValue<T>(T dummy) -the latter to avoid the use of the static <T> when calling the method, instead of GetValueVector3() and so on (ditto for the methods that return an array).
• SetValue<T>(T value), instead of overloading SetValue(...).

That way it could be easier -for us- to implement a sort of "fx parameter mapping" technique as well as an 'EffectParameterHandler' class without the use of casting and or (un)boxing and of course avoiding direct use of myEffect.Parameters["parameter1"] and such.

Shawn Hargreaves - MSFT

We actually did use generics for this in early versions of the framework design, but it turns out that isn't such a good idea.

When it comes to actually implement these methods, there is no way to do that generically: you need different code for every possible type to call the appropriate native D3DXEffect methods. So if you make the API use generics, inside that method you end up having to have a giant switch statement that examines the type parameter to figure out which code to run. That's slow. Plus, what do you do if you're passed a type that you don't know how to handle You just have to give up and throw an exception, but now you have a confusing API because although it can really only handle a limited set of types, it isn't obvious from the API signature what types those are, you just have to try each one and see if you get an exception.

It turns out to be a lot faster and simpler just to expand out separate overloads for each supported type.

Ultrahead

So if you make the API use generics, inside that method you end up having to have a giant switch statement that examines the type parameter to figure out which code to run. That's slow. Plus, what do you do if you're passed a type that you don't know how to handle You just have to give up and throw an exception ...

Yes, it's what I'm doing right now ... My code analyzes the type of parameter passed so as to call the proper method or throws an exception for unknown ones ...

So different question: any chance of unsealing the "EffectParameter" class so that the base class remains intact and each user could still extend it

Shawn Hargreaves - MSFT

Even if EffectParameter was unsealed, how would you construct your own instances of your custom type The only way you can get an EffectParameter today is by looking up the ones that are created for you when you load an effect - there'd still be no way to hook into that to make it create some other type of your own.

I'm guessing you are looking up the EffectParameter instances created for you by the effect, then wrapping these with some other type of your own to use in your engine If so, why do you need the framework type unsealed I'd think your wrapper could just be a separate type that implements whatever functionality you want...

Ultrahead

then wrapping these with some other type of your own to use in your engine

Exactly ... ok, I'll keep my implementation for now.

I posted my question because I've seen today the code of the "EffectParameter" class (using Reflector) and as it checks for casting exceptions and the type of EffectParameterClass it was dealing with I just thought generics could be also impemented in that class.

Thanks anyway ...

Shawn Hargreaves - MSFT

Generics could be used, certainly, but they'd be significantly slower than the way it currently works.

Ultrahead

Could both kind of implementations coexist in the 'EffectParameter' class ... so that we can choose what to use: either the direct approach (overloading) or the 'generics' one ... at one's own risk ...  (last question on the matter, I promisse) ...

Shawn Hargreaves - MSFT

They could, but why

What do you gain from a generic method that you can't do using the current method overloads

Ultrahead

Well, my goal was to create a robust rendering process that draws objects by layer -> shader -> material -> texture -> etc.. So I decided to avoid the use of direct calling to each shader's parameter collection.

Instead, I use a "home-made" parameter mapping technique which is clean. So I thought it could be better with generics.

Now that you mention the performance issues, I cannot continue to believe that a priori (I'd need to test the trade-off: using generics with the gain of the rendering process or staying with the standard approach).

Maybe I need to think a bit further my rendering process without the use of generics.

Thanks.