No... In true, PVWp is wrong because P,V and W (as Direct3D defines) were created to satisfy the [row vector]*[matrix] multiplying order. In other words, the content of a transformation matrix could be different depending on the multiplying rule.
For example, consider a translation matrix:
For a [row vector]*[matrix] multiplying order, it is described as:
1 0 0 0 0 1 0 0 0 0 1 0 x y z 1
For a [matrix]*[column vector] multiplying order, it is described as:
1 0 0 x 0 1 0 y 0 0 1 z 0 0 0 1
I don't know the math details you're attempting to work out... I'm really bad at formal math theory. I do however know the D3D details of what's going on. Perhaps if I explain what D3D is doing, it'll help you.
Matrix in memory normally.
11 12 13 14
21 22 23 24
31 32 33 34
41 42 43 44
Normally a vector * matrix such a D3DXMatrixTransform will do:
outx = vec dot (11,21,31,41)
outy = vec dot (12,22,32,42)
outz = vec dot (13,23,33,43)
outw = vec dot (14,24,34,44)
When you give a matrix to a shader, it is transposed, which offers a small optimization for most matrices, which I'll explain in a bit. After it's transposed, it's stored in 4 constant registers (or 3... I'll get to that).
c0 = 11,21,31,41
c1 = 12,22,32,42
c2 = 13,23,33,43
c3 = 14,24,34,44
Next, in the shader performing a "mul(vec,mat)" will do this:
v0 = input register containing position
r0 = temp register
dp4 r0.x, v0, c0 // (r0.x = v0 dot c0)
dp4 r0.y, v0, c1
dp4 r0.z, v0, c2
dp4 r0.w, v0, c3
As you can see, this is the same as D3DXMatrixTransform. Why does D3D perform a hidden transpose? To save precious constant space. You can declare your matrix as float4x3 and the transformation becomes:
dp4 r0.x, v0, c0
dp4 r0.y, v0, c1
dp4 r0.z, v0, c2
mov r0.w, (some constant holding 1)
Any time the matrix isn't a projection, ie: for world, worldview, view, and bones especially, you can drop a constant without affecting the results, as it's always a (0,0,0,1) vector. Back in shader 1.1 with only 96 constants, it was a big deal. If you had 20 bone matrices, that would be either 80 or 60 constants. Personally, I'd take the 60, leaving more room for lights, fog, texture transforms, etc. It also takes time to upload all those useless (0,0,0,1) vectors to the video card, which is another small savings.
]]>
isatty is used by the lexer to determine if the input stream is a terminal or a pipe/file. The lexer uses this information to change its caching behavior (the lexer reads large chunks of the input when it is not a terminal). If you know that your program will never be used in an interactive kind, you can add %option never-interactive to you lexer. When the program is run with user input, use %option interactive. When both uses are desired, you can either generate an interactive lexer, which gives a performance loss when used in batch mode, or provide your own isatty function.
]]>
1)) manifest WIN32 set Yes, 2)) ignore msvcrt.lib
/*
Hi there,
I read every post in this thread without any help in my case.
The problem turned out: The DEBUG version was trying to link with BOTH msvcr80.dll and msvcr80d.dll.
Check if this is the case for you using the "dependency walker" on your executable. If these two are both loaded, then you got the same problem as I did.
The solution is to set "Properties->Linker->Input->Ignore Specific library" to "msvcrt.lib".
More details below:
I was compiling and running a program that uses opencv library. One of the libraries in opencv (highgui to be exact) was linking with non-debug versions of some graphics libraries even in its debug version. Apparently this was OK before.
This resulted in my debug version program linking with both msvcr80.dll and msvcr80d.dll. It appears this is a problem since the manifest only mentions one of these libraries and the other one (msvcr80.dll) appears not to be found causing the error mentioned in this thread. Why no-one in this thread mentioned that this could be the case is beyond me. I found out about this using "dependency walker" on the .exe that I compile and/or the highgui100d.dll that I load from the library.
That is the reason the complaint is about msvcr80.dll and not msvcr80d.dll in VS8!!!
The fix is to re-compile highgui100d.dll (debug version) with Properties->Linker->Input->Ignore Specific library set to singly "msvcrt.dll".
Just wanted to add this so other people do not waste time as I did...
Hakan
*/
2) MFC
MFC 浠嶸C6鍒癡8鍙樺姩寰堝ぇ錛?br>// VC8
LRESULT CDialogBar::HandleInitDialog(WPARAM, LPARAM)
{
Default(); // allow default to initialize first (common dialogs/etc)
// create OLE controls
COccManager* pOccManager = afxOccManager;
if ((pOccManager != NULL) && (m_pOccDialogInfo != NULL))
{
if (!pOccManager->CreateDlgControls(this, m_lpszTemplateName,
m_pOccDialogInfo))
{
TRACE(traceAppMsg, 0, "Warning: CreateDlgControls failed during dialog bar init.\n");
return FALSE;
}
}
return FALSE;
}
//VC6
LRESULT CDialogBar::HandleInitDialog(WPARAM, LPARAM)
{
Default(); // allow default to initialize first (common dialogs/etc)
// create OLE controls
COccManager* pOccManager = afxOccManager;
if ((pOccManager != NULL) && (m_pOccDialogInfo != NULL))
{
if (!pOccManager->CreateDlgControls(this, m_lpszTemplateName,
m_pOccDialogInfo))
{
TRACE0("Warning: CreateDlgControls failed during dialog bar init.\n");
return FALSE;
}
}
return TRUE;
}
绔熺劧鏈夎繖涔堝ぇ鐨勫尯鍒紝鍚屾椂鐪嬩笉鎳俈C8涓轟粈涔堣閭ｄ箞浣?/p>
]]>