Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

asmLOCK

DirectDraw debugging

This topic is 6970 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Unfortunately, a really useful extension by Microsoft (surprise!) to C++ in this scenario is the 'try...finally' compound that lets you contain dangerous code in the try and if ANY exception is raised the code in the finally will be executed. Check into it to see if Borland has an equivelent extension.

The only other thing I can think of is don't write code that raises exceptions, but sometimes that can be hard.

What kind of exceptions are you dealing with? I would hope you would know what code regions could cause an exception and protect them in one way or another. Exceptions are a sign that you are feeding / using data / parameters that are invalid, which is generally a sign of underlying problems in your code. Fixing those problems will save you frustration in the future.

Also, wrap your low-level and system calls in nicer functions that can be carefully anaylsed and 'try...catch'ed. Then forget about exceptions.

- Splat

Share this post


Link to post
Share on other sites
Advertisement
I tried this:

***************************************

try
{
//my function to draw a filled circle...
Circle_Draw(x, y, color, radius);
}

//catch ANY exceptions with "..."
catch(...)
{
//unlock surface
DDSBack->Unlock(NULL);

//hide the window so
//I can see the debugger
DDCanvas->Hide();
}

***************************************

It still locked up, but I found where the problem was anyway. I wonder if the debug version of DirectX will help me with that locking up, but hurt my regular game performance???

Borland does have "finally", but in the code examples I saw, the catch(...) appeared to do the same thing(catch ANY exceptions thrown).

------------------
When life hands you lemons, throw them at God's head.

Share this post


Link to post
Share on other sites
Two other things you can try:
When locking, pass the DDLOCK_NOSYSLOCK flag. This can sometimes let you debug into locks (or at least not lock yourself up!). Second, if you're locking the backbuffer or front buffer, instead (maybe only for debugging) work with an offscreen, system memory surface. Sometimes this lets you debug inside a lock when it would otherwise lock up.
-ns

Share this post


Link to post
Share on other sites
Alright gang, here's my situation...I'm writing a 2D graphics library to draw filled circles, polygons etc. I use Borland C++ Builder 3 and DirectX7...here's the problem:
Every time one of my functions causes an exception while my surface is locked during a blit, I have to reboot! This can (as you might imagine), drive you insane...so I'm wondering if anyone knows what I can do to prevent these little mishaps. Will installing Directx debug version help or not?
Should I use "try" & "catch"(and what type of exception do I catch)?

------------------
When life hands you lemons, throw them at God's head.

Share this post


Link to post
Share on other sites
Here's an idea Go get yourself Windows NT. I am using NT4.0SP6 with DirectX 3 (yeah I know). As such you can guess I don't use Direct3D, my game is 2D though so that is not a big deal. It doesn't lock up my computer when something goes wrong in there, I just gotta Alt-Ctrl-Delete and End Task the bugger. NT seems to allow that key even if you have DDraw set to ignore it

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!