I''ve got a little problem with my game. When I compile it in "debug version", all is well. But in release version, it crash when i try to set a specific texture (using D3D 7). Something special with this texture is that it''s created by D3DXCreateTexture then D3DXLoadTextureFromSurface. I suppose this last function is supposed to create a separate copy of the texture, so releasing the original texture should not affect the copy? And what could make a program which work in debug version hang with the release one?

In my experience, timing can cause this. Anytime more than one thing is happening at the same time and they need to coordinate with each other, timing is important. Things tend to happen faster in release code and this can sometimes expose timing problems.

If you are multithreading, you need to make sure that the threads are synchronizing properly. Never ever assume that a thread will complete a task in a certain amount of time. You should always have some kind of message passing to indicate that the task has been completed.

Also, I''m a little rusty on DirectX stuff, but I think when you send or receive data to your graphics hardware, there are flags that tell your code to block until the data transfer is complete. If you aren''t using those flags, then I believe there is a function that you can call that will query to see if the transfer is complete yet. You need to either use the blocking flags or use the polling function to make sure the data is transferred before continuing with the program.

Thanks, i''ve solved the problem. It was not about timing or multithreading, but a variable I forgot to initialize. Apparently, it was initialized to 0 in debug (which was the right value, so it worked) but not in release.

Oh yeah, forgot about that. Variables get init''ed to 0 in debug mode.

Anytime I am writing something that I plan to release eventually, I check regularly to make sure it still compiles and runs in release mode.

I just want it to say, there can also be another problem:
pointers
in debug-mode a lot of memory is used to store debug-information. Actually this memory won''t be used by the debugger. If you now, for example, use an input buffer for a function and you pass a wrong length to the function, the function can write into the debug-mem. But in release builds other parts of your program may lurk around at that position. Hope it is clear for all of you.


B.o.t.G.
--------

Writer of
- VQAtoAVI, the conversation utility for C&C
- Golden Cow, the BO2K attacher