Implement GetParameterB​ySemantic

[tomspilman]

To implement EffectParameterCollection.GetParameterB​ySemantic() we need to first extend the MGFX parser to parse out semantics in parameter definitions. We can then include the semantic in the compiled .mgfx file and used from the EffectParameterCollection and EffectParameter types.

[tomspilman]

Note I originally skipped implementing this because to me it seemed the parameter name and semantic were largely duplicate information. Why look up by semantic if you can by name?

[gabereiser]

normally semantics are used when the engine fills the pipeline with default data (view, projection matrices) while allowing developers to use their own programming code design guidelines.

[tomspilman]

@gabereiser - I'd love to see one example of where semantics are more useful than the name.

[gabereiser]

@tomspilman my own engine reactor, uses it to hydrate shaders. https://github.com/gabereiser/reactor
Look in XNA/Reactor3D/Lighting.cs to see that a material will fill in per frame parameters by looking up shared known semantics. I've implemented something similar in my new engine that's pure OpenGL by using regex parsing of glsl before compiling.

[mgarstenauer]

Why look up by semantic if you can by name?

Since MonoGame does not support semantics, we had to rename all our effect parameters to match the semantic name. No big deal, but I personally prefer using semantics:

• Engines usually have to support a lot of different effect parameters. As a result the semantics are rather long and unwieldy, such as "WORLDVIEWPROJECTIONINVERSETRANSPOSE" (used in DXSAS) or "DIRECTIONALLIGHTSHADOWMAPSIZE" (used in our engine). When using semantics we can keep the effect parameter name short. This keeps the code readable and makes editing more comfortable.
• It is easier to rename/change semantics as they are specified only when the effect parameter is declared. Renaming effect parameters - which usually does not happen that often - is rather inconvenient. Renaming with "Find And Replace" is less robust than e.g. refactoring C# code.
• In theory, it is easier to reuse existing HLSL code: Just attach the semantics used in your engine and the HLSL code can stay the same ... at least for simple effects.

So I would argue semantics are not essential, but "really nice to have".