D3DXVec3Normalize

Started by
14 comments, last by evanofsky 19 years, 1 month ago
Well, I wrote a quick test app, and just as I suspected... it worked. :'( It must be something to do with some other function accessing it or something...
Advertisement
I tried putting the code from the test app into the code in my game, and it just returned {0, 0, 0}. So there's some kind of setting... maybe D3DRS_NORMALIZENORMALS? I'll try messing with that a bit.
Check for stack corruption around the code. This can be caused by incorrect pointer arithmetic, causing usage of wrong memory addresses (thus zeroing incorrect variables, maybe?).

Niko Suni

Quote:Original post by evanofsky
I tried putting the code from the test app into the code in my game, and it just returned {0, 0, 0}. So there's some kind of setting... maybe D3DRS_NORMALIZENORMALS? I'll try messing with that a bit.
The D3DX vector and math library of functions don't access the device at all. So setting renderstates shouldn't affect anything.

As for the stack corruption, try declaring a large array (try 100,000 chars) before your vector, that should put the vector into stack space that hasn't been modified yet (in theory).
Also, try writing a function that normalises a vector and returns it, something like this:
D3DXVECTOR3 myNormalise(const D3DXVECTOR3& v){   D3DXVECTOR3 vRet;   D3DXVec3Normalize(&vRet,&v);   return vret;}

See if that works.

Of course if either of those do work, then you'll obviously have to find out *why* they work, since it's going to be some kind of stack corruption. Don't assume "Oh, it works now, thats ok then", otherwise you're likely to get problems like this popping up in the future.
Quote:Original post by Evil Steve
Don't assume "Oh, it works now, thats ok then", otherwise you're likely to get problems like this popping up in the future.


Agreed 100%. Memory corruption errors are among the most evil errors available, because they can be random and seemingly consequence-free - yet able to bring a machine to a full stop unexpectedly (common when dealing incorrectly with device address spaces like locked hardware textures and such).

Niko Suni

Alright, I fixed it. This is gonna kill you all. I have a function that converts numbers to strings. I was using it to convert the x,y, and z components of the normal so I could make a MessageBox with the coordinates. Well, apparently the function didn't work, and it was giving 0s and 1s to me the whole time. The real problem was actually in my vertex shader!! I'M SO SORRY I TOOK ALL YOUR TIME!! Thank you for helping me, though!

This topic is closed to new replies.

Advertisement