I had this problem where some of my polygons were flickering. At first I wasn’t sure what was going on, then I realized I had 2 present calls in the same frame.
Thanks D3D11 for removing BEGINSCENE/ENDSCENE??!! Anyway, that was an annoying bug to find.
An amazing error,
D3D11: ERROR: ID3D11DeviceContext::Draw: Vertex Shader – Pixel Shader linkage error: Signatures between stages are incompatible. Semantic ‘TEXCOORD’ is defined for mismatched hardware registers between the output stage and input stage. [ EXECUTION ERROR #343: DEVICE_SHADER_LINKAGE_REGISTERINDEX ]
What this error means is you didn’t match up EXACTLY the ORDER of the OUTPUTS you your vertex shader with the INPUTS of your pixel shader.
For example, the following CG shader triggers the error:
void vertexMain(
in float4 ip : POSITION,
in float3 N : NORMAL,
in float4 ic : COLOR,
// 4 outputs, in this order
out float4 op : POSITION,
out float4 oc : COLOR,
out float4 posToPxShader : TEXCOORD0, // original space pos
out float3 normToPxShader : TEXCOORD1,// original space normal
// the concatenated modelview-projection matrix
uniform float4x4 modelViewProj
{
// vx shader code..
}
void pixelMain(
//THIS PIXEL SHADER MUST RECEIVE
// ALL 4 OUTPUTS OF THE VERTEX SHADER,
// IN THE EXACT ORDER THAT THE VERTEX SHADER
// OUTPUT THEM, OR YOU WILL GET AN ERROR
// COMMENTING OUT THE LINE BELOW TRIGGERS THE ERROR
//in float4 tp : POSITION, // transformed space position // must rx b/c is output of vshader stage
in float4 ic : COLOR,
in float4 ip : TEXCOORD0,
in float3 N : TEXCOORD1
{
// pixel shader code..
}
I was having a problem with a common C++ pattern:
//file1.h #include "file2.h" // file2.h #include "file1.h"
The header cross-inclusion sometimes results in compilation errors if “file1.h” requires a type from “file2.h” to be fully defined, and vice-versa.
So, what I started doing is stop #including every header file in every other header file and use forward declarations instead, and include the required header file in the code file that uses the class definition.
This can happen if you forget to call cgD3D9SetDevice( NULL ) ; before closing your application.
It is my opinion that globals are necessary __sometimes__.
You just can’t get around the fact that you need them, at times.
You can think of a member variable as actually .. a global variable.. within that class!
The best reasons NOT to use globals are
The problem with global variables is that since every function has access to these, it becomes increasingly hard to figure out which functions actually read and write these variables.
So to understand how the application works, you pretty much have to take into account every function which modifies the global state. That can be done, but as the application grows it will get harder to the point of being virtually impossible (or at least a complete waste of time).
– Brian Rasmussen
It’s better to talk about size of scope than whether or not something is global. “Global” just means maximum scope. Instead of saying “global variables are bad,” I think it’s more helpful to say “minimize variable scope.”
A global variable in a 100-line program has a scope of 100 lines. But a member variable in a 1000-line class has a scope of 1000 lines. The latter may be worse.
Some say globals are seen as bad because of their bright scope.
Bobobobo's Weblog 