🔒 Locked

Release, Debug Anomaly

Started by Cold_Steel Nov 5, 2002 at 10:49 PM 3 replies 250+ views

Original Post

Nov 5, 2002 at 10:49 PM

Alright, here's my problem/observation. I created a soft skinned skeletal animation system using software vertex shaders. When I compile and run using VC++ 6, in retail mode, running either the retail or debug Direct3d drivers, everything works exactly as expected. It displays the model where it should, the animations look fine, everything is great. Now, if I switch to debug mode in VC++, with either debug or retail drivers running, things get wierd. The model is drawn up about 10-20 units I'd guess, though its hard to tell. The model is also incredibly stretched, and it may be upside down, it's really hard to tell. I can run animations, but the model is totally screwed up. I wouldn't mind, but I'd really like to be able to use debug mode in the rest of the projects I'm going to create using the modeling system. I've tried recompiling and starting new projects, but it doesn't seem to help. I can't really figure out what the deal is. I believe the problem started after I started using animations, instead of just static models. If no one has any idea, I'll try reinstalling VC++ to see if something got screwed up somewhere. I'll let you know if I find anything else. Thanks a bunch. [edited by - Cold_Steel on November 7, 2002 8:12:34 PM]

niyaw

Nov 5, 2002 at 11:43 PM

try defining _DEBUG manually, and building a release build. if the problem persists, it''s likely a bug in your code.

Kippesoep

Nov 6, 2002 at 4:58 AM

Most likely caused by an unitialised variable somewhere. MSVC Debug builds will set memory to specific values upon allocation/deallocation. Perhaps you''re relying on certain values (possibly zero?) that you get in Release builds. That''s a very bad idea, though, because the values are extremely unlikely to be the same every time you run the program.

Try setting breakpoints at appropriate times (creating/filling the vertex buffer would seem as good a place as any) and see if there''s anything in your data that has hex value 0xCCCCCCCC (unitialised debug memory).

Oh, BTW, I had a similar problem trying to use one vertex buffer for both software and hardware vertex processing. Had to use two separate ones.

Cold_Steel

Nov 6, 2002 at 9:58 AM

quote:
Original post by niyaw
try defining _DEBUG manually, and building a release build. if the problem persists, it's likely a bug in your code.

Okay, I did a

#define _DEBUG

at the top of my main.cpp file, and compiled using a release, and everything works just fine. I assume I did the define right.
I'll keep looking...

Okay, I just found something, I was using blend weights for each vertex and binding it to 2 bones at once, now, when I set the threshold to 0, ie each vertex will only bind to one bone, I get rid of the stretching, makes sense.

The problem is that each bone is way off in different directions. There must be a bug somewhere in my matrix translation, but its wierd that it works perfectly in release mode, but not debug.

[edited by - Cold_Steel on November 6, 2002 11:02:54 AM]

Cold_Steel

Nov 7, 2002 at 3:33 PM

Okay, I figured out my problem for anyone who wants to know.

in updating my bone matrices I had the line

localMatrix = translation * rotationX * rotationY * rotationZ * (*D3DXMatrixInverse(&translation, NULL, &translation));

this was the cause of it all. In release mode, it appears that
*D3DXMatrixInverse(&translation, NULL, &translation) is the last thing done on that line. In debug mode, however, it appears to be the first thing, and what happens is translation gets modified with inverse, and then is multiplied again at the beginning, giving bizarre results. Strange it gets run differently in different modes...

Also, as an optimization question, would it be faster to just have two translation matrices, one with the positive translations, and the other with the negative translation, instead of using inverse, which I presumes, takes more time.

________________________
Grab your sword, and get prepared for the SolidSteel RPG engine, coming soon...(i.e. when it''s done

)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.