General MDXInfo tutorial FAQ By Rim van Wersch, March 24 2006

We've occasionally received feedback on our tutorials in which common questions are frequently asked, so we decided to put them together in a little FAQ here to clarify a few things on HLSL and some of our tutorials in general. Thanks goes to Jonas for pointing out the need for this useful section.

» Got another question/comment you think should be added to this FAQ? Please !



General | Which .NET framework and MDX version do you use?

Our tutorials and samples are mainly written for the .NET 1.1 framework and the corresponding MDX 1.1 libraries. Some code samples already use the .NET 2.0 framework, but these should have the .NET 2.0 framework listed in a prerequisites section. If you spot a resource where this is not the case, .

We haven't used MDX 2.0 just yet since it's still in beta at the moment. Once it comes out of beta and .NET 2.0 debugging issues have been solved, we'll probably switch over to this platform. At that time, we'll also add some markers to our resources and tutorials indicating which platform they're intended for.

General | I see no reason why a simple tutorial takes 16 pages, please explain.

» This one only applies to the more advanced HLSL tutorials and a few others, 16 pages in multiple files, so no worries

We've thought about this too and recognize the need for simple tutorials. The problem is, we wanted to work out the tutorials in a simple consistent framework, so Pieter (the author of our basic tutorials) fixed up a basic engine to demonstrate how things could be done to get into 3D app design right away, rather than showing the bare basics and forcing people to reaquaint themselves with more advanced methods later.

Some samples I (Rim) wrote on the other hand use the SDK's sample framework to get things done quickly. I tried to hide as much of the framework related code as possible in #regions, but unfortunately it indeed still has to compile and link those files. The sample framework does take some getting into, but once you're accustomed to the structure it should be quite clear what's going on. More information on the sample framework can be found in the Managed SDK docs, under DX SDK -> Introducing DX9 -> Direct3D Graphics -> Sample framework or over here on MSDN.

General | How can I get the Sample Framework to work on a Control instead of a Form?

Visitor Sašo pointed out this project on GotDotNet which apparently managed to use the sample framework on a Panel successfully.

HLSL | Why do you pass a POSITION semantic from the vertex shader to the pixel shader when you don't use it?

The POSITION entry *must* be returned from the vertex shader, so we typically pack that into the vertexshader -> pixelshader structure. The POSITION semantic simply has to leave the vertex shader (either through a return or as an OUT parameter) so it can be picked up correctly by the effects framework.

This may seem puzzling at first, but the transformed vertex position has to get to the rasterizer even if it's unused by the pixelshader that's run afterwards. A HLSL shader most likely won't even compile when you don't output a POSITION (or equivalent POSITION0) semantic from the vertex shader.

HLSL | Why do you use out parameters and not returns from shader functions?

It's the way NVidia typically uses so it's more force of habit than anything else. It may be a bit confusing at first, but we found it is a bit neater in the long run. You can typically specify OUT.Position = someValue; for example, without having to allocate the OUT struct first and returning it afterwards. We're not entirely sure, but there also seems to be a marginal performance gain in this, since the effect can reuse the same struct 'object' time and again for each vertex/pixel.

HLSL | Why do you sometimes define semantics for global shader variables?

Semantics on globals are only needed when you intend to reference these globals by their semantic meaning, which is indeed not common but occurs occasionally in NVidia shaders. It can also be used in C# code by using Effect.GetParameterBySemantic to make the shader<->app interaction agnostic of the internal shader variable names. Lastly, the semantics within the effects-framework are quite standardized, so these may sometimes serve to clarify the semantic meaning of a global parameter.