Better error when VertexFormat doesn't match shader

[theZMan]

During MVA demo had a cased where a models vertex format mismatched with the shader input format.

The error you get is below. @tomspilman says he can make that better.

An unhandled exception of type 'SharpDX.SharpDXException' occurred in SharpDX.dll

Additional information: HRESULT: [0x80070057], Module: [General], ApiCode: [E_INVALIDARG/Invalid Arguments], Message: The parameter is incorrect.

[tomspilman]

I'll see if I can spend some time on this.

The crash comes from here:

https://github.com/mono/MonoGame/blob/develop/MonoGame.Framework/Graphics/GraphicsDevice.DirectX.cs#L1113

Basically I need to catch that exception and report something useful to the user. I suspect I can at least report the vertex format in the VertexDeclaration and say it doesn't match the vertex shader.

[tgjones]

I started to have a look at this, because I hit this issue myself and it took me a little bit of time to figure out - I imagine it's pretty confusing for beginners. XNA gives a nice error message:

The current vertex declaration does not include all the elements required by the current vertex shader. Position0 is missing.

I've got as far as adding a failing unit test. But unfortunately ShaderReflection, which gives us access to the input parameters and semantics, is part of SharpDX.D3DCompiler, which isn't (and shouldn't be) available at runtime.

So I see two options:

1. Pass [an efficient representation of] the input parameter and semantic data along the content pipeline with the rest of the shader metadata, so it's available at runtime. This means we can give precise error messages. (I haven't checked, but perhaps we need to do the same for the linkage between vertex shader output / pixel shader input).
2. Just throw a more general exception - at least, we can include the vertex format in VertexDeclaration. Note that we'd have to do this every time the InputLayout constructor fails with an InvalidArg exception, which probably isn't correct - I imagine there are other reasons that that constructor can fail.

I like option 1, but it does mean a change to MG's compiled effect format. What do you think? @tomspilman @theZMan

[tomspilman]

I hate the idea of adding stuff into the format just for better error reporting. It means every effect is a little fatter and we use a little more memory to provide this feature.

To me number 2 is a good option that will point users in the right direction without any additional overhead.

[tgjones]

Fair enough - I've created a PR with option 2. (I think I remember spotting it happen in your MVA presentation, and because I'd had it happen a couple of days before, I knew immediately what it was - but it definitely wasn't an intuitive error message.)

[tomspilman]

I think I remember spotting it happen in your MVA presentation

It totally did and confused @theZMan . Glad to see a more obvious message now!