Hi ! I''m used of writing full-screen DirectX 6.0 applications, but now I''m writing a tool in windowed mode.... Now, for some reason everytime my code reaches the surface->Lock(... ) function the system halts and I have to reboot. I''ve tried both to lock the whole surface (NULL) and a rectangle, no difference. I debugged several times and verified every return code, everything seems to work fine,... until I reach the line with ''Lock''. Any ideas ? Kind regards, Christophe ''Uther Pendragon'' Cap PS. I already installend my ''MonsterFusion'' drivers as well as the directX SDK

What code do you have inside Lock - Unlock?

Gandalf the White

Locking the screen is likely killing your debug session. Try using a log file to do your debugging

When debugging your locking code try putting the flag:
DDLOCK_NOSYSLOCK in your lock call. Then you should be able to step through the locking code. I don't think it works for when you are locking the primary surface though.

Edited by - ao on 2/2/00 11:54:51 AM

Hi,

Well, the purpose of the lock is drawing som pixels on a part of the window.µ ---> But, I NEVER get there, the system crashes ON the lock not after.

How do I use a log file for debuggin ?

In the meantime I got a repla from Stephane Schmidts on the Microsoft DirectX forum, he appears to have the same problem. He has no solution either.

Do I have to write special setup code to create DirectX in Windowed mode ? I only changed the SetCooperativeLevel to normal....


Still hoping to find a solution....


Thanx,

Christophe

I''ve never written a windowed application, but I do know how you can take it completely out of debug mode if you''re using VC++. Click on build, scroll down to "active settings", or something like that, and click on it. Then you should see a window that has "Win32 Debug" and "Win32 Release", change the selection to "Win32 Release", and recompile. Who knows, it might work .

You can''t step through the direct-x lock call with a debugger. the instant it gets in, all GUI processes cease until the lock is released. Normally you don''t notice this, as its very quick.. but when your debugger hits the line, it sits and waits for you to jump to the next instruction. Of course, you can''t push the button to go to the next instruction, since the gui''s locked... If you''re lucky, a soft boot is possible.

to debug with a log file, simply create a text file at the beginning of your program (or draw loop) and output any information or messages you would like to recieve as your program runs. Run the program, and read the log file to see what you wrote.

If the lock call is failing on normal operation, thats a bit more tough. I personally have a very difficult time successfully using lock to write to the framebuffer at all in windowed mode... tends to crash alot. My advice is to stay in full-screen Exclusive and debug with the log file, or create your own in-game debug tools.

Forgive me if this is a stupid question, but did you initialize your direct draw surfaces correctly? It requires a slightly different setup in windowed mode.

1) You don''t use the DDSD_BACKBUFFERCOUNT flag or the dwBackBufferCount flag when creating the primary surface. Instead, you create an DDSCAPS_OFFSCREENPLAIN surface after you create the primary surface. Then use the plain surface for a back buffer.

2) You create and attach a direct draw clipper object. The easiest way to do that is to use lpdd->CreateClipper(...). Then you attach it to the primary surface with lpddsPrimary->SetClipper(...) and set the HWND with lpddClipper->SetHWnd(...). The HWND is your program''s main window.

3) If you''re using Direct3D, you should specify the DDSCAPS_3DDEVICE flag with your DDSCAPS_OFFSCREENPLAIN surface.

4) Instead of flipping, you call Blt() (or something similar) from the primary surface, specifying the back buffer as the source surface.

I think that''s all of the differences. Otherwise, all your code should work the same

- null_pointer

Hey you guys or girls... you can debug your code line by line when locking a surface. I have done it many times with VC++ 5.0 in debug mode. I understand that lock completely locks up all system processes, but that is the purpose of DDLOCK_NOSYSLOCK - no system lock.

I know this may not be udragons problem but if you believe you must create a file to write info to within a locked portion of code you are wrong.

I suggest giving it a try.

You can also try to use Win 2000, then you will be able to Debug when you have locked your program...