Print

[BenJeremy]

QUOTE (outRider @ Aug 8 2003, 08:07 PM)

I have an indexed triangle list. Culling is set to CW, triangled are CCW wound. Now, when I run the release build... everything is correct. When I run the debug build with the debugger attached... everything is correct. When I run the debug build... the culling mode seems to be set to CCW and everything appears inside out. This happens without fail. I've looked at my code and I'm not accidentally setting or resetting the cull mode. I check the cull mode right before rendering and it's always correct, and yet I get triangles facing the wrong way. I've checked using both the fixed function pipeline and using vertex shaders, same result. I'm using XDK 4627. Starting a clean project and rebuilding from scratch doesn't work. Anyone have any ideas?

Easy one.

Somewhere, you have an uninitialized pointer or other variable. Under the debugger, all memory is initialized to cdcdcdcdcdcdcd... but when running 'normally' - the memory is not initialized (or initialized to zero) and the results change.

Double check your constructors.

[BenJeremy]

QUOTE (outRider @ Aug 9 2003, 12:11 PM)

Actually, I've narrowed down the problem to something simple, though now I just have more questions than answers. I have two modules that draw to the screen. Module A, the one that gets rendered inside-out, was always working and I hadn't touched it. The bug was introduced while I was working on module B, all of a sudden A started to render incorrectly, and I've narrowed it down to CODE CSkymap::Parameters  SkyOptions; Declaring a copy of that struct on the stack causes module A's rendering to screw up. That struct is part of module B. I thought I was running out of stack space, but I'm not even close, I'm using about 5-10KB with a stack of 64K, and the disassembly looks fine. As for the pointer thing, there's no pointers involved. Besides, pointers are initialized in debug builds regardless of whether or not the debugger is attached, as far as I know. My bug shows up only when I execute in debug mode without the debugger attached. It works fine with the debugger attached and in release build. I'm thinking either the problem is not the above struct, or that there's a bug in 4627.

Not JUST pointers... that would throw exceptions and do God Knows What.

Even a simple uninitialized variable can do the damage. Is your constructor fully initializing every member, and is each member doing the same for it's members (and so on)?

Your stack memory would be constantly changing, so a class/struct allocated form that "pool" of memory would show random results on uninitialized members.

[Wishi]

Why use the stack then if it's causing the problems?

[KDragon]

[EvilWays]