HOWTO: How to Debug DirectDraw Applications

ID: Q147256

1.00 WINDOWS kbhowto kbtshoot

The information in this article applies to:

Microsoft Windows Software Development Kit (SDK) 3.1

SUMMARY

There are two common needs when debugging DDraw applications:

Debugging a fullscreen application.

Debugging code between Lock and Unlock or GetDC and ReleaseDC calls.

MORE INFORMATION

The best way to debug fullscreen applications is to use remote debugging; that is, running the debugger on one computer and the application on another computer.

Whenever Lock or GetDC is called on a video memory surface, a Win16 Mutex (also called Win16Lock) is taken. Due to this, standard application debuggers such as Microsoft Visual C++ will not be able to debug the code that lies between Lock and Unlock or GetDC and ReleaseDC calls. A kernel debugger such as WDEB386 (provided with the Win32 SDK) or a third party debugger such as SoftIce for Windows 95 from NuMega Technologies must be used instead.

An alternative option for debugging a non-primary surface is to force an offscreen surface to use system memory. For example:


   #ifdef _DEBUG

   ddsd.ddsCaps.dwCaps = DDSCAPS_SYSTEMMEMORY |
           DDSCAPS_OFFSCREENPLAIN;

   #else

   ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN;

   #endif

When a surface is explicitly requested to be allocated in system memory, Lock and GetDC do not take the Win16Mutex. If a surface is not specified to be placed in system memory but is allocated there anyway because there is not enough video memory available, the Win16Mutex will still be taken when the surface is locked.

REFERENCES

For more information, please see the following article in the Microsoft Knowledge Base:

Q125867 Understanding Win16Mutex

Additional query words: 1.00 DDraw debugging


Keywords          : kbcode kbSDKWin16 
Version           : WINDOWS:3.1
Platform          : WINDOWS 
Issue type        : kbhowto

Last Reviewed: June 21, 1999