Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Intercepting Errors

Author
Message
G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 27th Nov 2006 07:46
Is there a way to intercept errors that occur in the DGSDK engine (For example if you try to access a object's limb that doesn't exist)? The engine doesn't seem to raise an error that could be caught with a try/catch block, it just seems to fail silently. Having it actually raise an error would certainly make things easier to debug.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
James Bondo
17
Years of Service
User Offline
Joined: 12th Nov 2006
Location: Denmark
Posted: 27th Nov 2006 16:00
Make it a habbit ALWAYS to check yourself. As of now, there is no way of knowing.

When you create an object, use ObjectExist() right after to check if it was successful. Same goes for all other kinds of create commands.

Proud member of The Unforgiven Warriors
http://www.tuwguild.com
lwatson
17
Years of Service
User Offline
Joined: 17th Nov 2006
Location: Lincoln, RI USA
Posted: 27th Nov 2006 16:37
Well

In the above example. There is a call to check for the existence of a limb on an object prior to attempting to do anything with that limb. So while the engine may not toss an error or that an error will be untrappable in Try Catch. Their may be ways of doing the check before the call like C programmers have had to do for some time rather than relying on the try catch mechanic to capture the errors afterwards.



Lonnie Allen Watson
rmag.blogspot.com (blog)
G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th Nov 2006 04:42 Edited at: 28th Nov 2006 04:43
If I'm not mistaken, this is all based on the Dark Basic engine. That engine raises errors that can be interecepted by the debugger. Why would I want to burden a system that is supposed to be as quick running as possible with extra function calls all the time? That is why try catch blocks exist. How can you write a fast running game with all of those extra calls in there? An error condition is (or atleast should be) the exception and not the rule. Therefore, why squander clock ticks needlessly to intercept the odd error case that occurs infrequently.

All of this is of course beside the point. In order to debug this problem I've been forced to resort to code that looks like this:



I've placed similar Debug.Print's after every call to the DGDK.Net engine that creates a DBPro equivalent command in the Debugger's output window with evaluated variable values. I can then copy all of this into DBPro, compile and find the error. Unfortunately, the program runs errorlessly in DBPro and fails silently in DGDK.Net. All I get is a black window. See the attached for a comparison. Does DGDK.Net have issues with cloning objects? That's all I can think of...

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro

Attachments

Login to view attachments
APEXnow
Retired Moderator
21
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 28th Nov 2006 12:56
G Man, catching errors in DGDK.NET still requires work because this is also the same for DGDK (C++). Cloning is working fine in DGDK.NET, but I can only assume that you are trying to load an object but it cannot locate the textures for that object?

Paul.

lwatson
17
Years of Service
User Offline
Joined: 17th Nov 2006
Location: Lincoln, RI USA
Posted: 28th Nov 2006 13:01
Have you ever seen the performance hit you take in a typical try catch under .Net...

Its like 500 milliseconds...

Lonnie Allen Watson
rmag.blogspot.com (blog)
Mudbug
17
Years of Service
User Offline
Joined: 2nd Nov 2006
Location: Rome, GA USA
Posted: 28th Nov 2006 15:22 Edited at: 28th Nov 2006 15:27
I didn't find any performance hit with multiple runs of this test application. Maybe the performance hit you are talking about happens only when an exception is thrown? I didn't have time to test that part of the theory.



I actually get better numbers WITH the try / catch, but only about 20 milliseconds.

Here is a sample of my Results:

Without Try/Catch: 781
With Try/Catch: 722

-MudBug
lwatson
17
Years of Service
User Offline
Joined: 17th Nov 2006
Location: Lincoln, RI USA
Posted: 28th Nov 2006 15:48
Correct...

Sorry I meant to stipulate that the catch takes a LOOOONNNNNNG time. The point being that if you are going to catch a condition and do something other than gracefully exit stage left, then the performance hit on using try catch is much greater than incrementally looking for trouble along the way.....

Lonnie Allen Watson
rmag.blogspot.com (blog)
CattleRustler
Retired Moderator
20
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 28th Nov 2006 15:48
yeah, try-catch at half a second delay would be ludicrous as a continual known baseline delay.

Mudbug
17
Years of Service
User Offline
Joined: 2nd Nov 2006
Location: Rome, GA USA
Posted: 28th Nov 2006 21:49
If try/catch is used properly for exceptions, I don't mind waiting an extra 1/2 second to see an error message. LOL.

-MudBug
Miguel Melo
18
Years of Service
User Offline
Joined: 8th Aug 2005
Location:
Posted: 28th Nov 2006 22:30
Quote: "If try/catch is used properly for exceptions, I don't mind waiting an extra 1/2 second to see an error message."


A good point, well put! LOL

I have vague plans for World Domination
CattleRustler
Retired Moderator
20
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 28th Nov 2006 22:50 Edited at: 28th Nov 2006 22:52
I thought he meant he saw a half second delay every time a TRY was executed - that would be ludicrous, CATCH catching an exception can take its sweet time as far as I am concerned because by that point the exception has been thrown, so all bets are off anyway

lwatson
17
Years of Service
User Offline
Joined: 17th Nov 2006
Location: Lincoln, RI USA
Posted: 29th Nov 2006 03:14
That's my point about using it for anything except exit stage left. If you use it for anything like, 'if this fails try something else', well then performance takes a wack on the shins. Now using it to trap and exit with grace well that is what its for IMO...

Lonnie Allen Watson
rmag.blogspot.com (blog)
G Man
19
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 29th Nov 2006 05:13
Quote: "That's my point about using it for anything except exit stage left."


You see that is exactly my point. It is far better to "gracefully exit stage left" than to simply fail silently and leave the engine in an untennable state. Beyond that, verbose errors are a key tool used by every programmer in debugging code.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
lwatson
17
Years of Service
User Offline
Joined: 17th Nov 2006
Location: Lincoln, RI USA
Posted: 29th Nov 2006 18:00
Ok...

Again I misinterpreted the question, likely because I am in a similar situation with my own efforts. Unfortunately Failure is not a real option for me. ( The 3D scene is being driven by data not a static scene but dynamically generated based on defined rules, driven by varying patterns in health care claims data, decidedly undefined).
Through that lens I read your question and jumped to wrong idea. Though I can say that some things are trapped like moving an object that does not exist will toss an error in the debugger than can be caught with the try catch, but others just don't seem to do anything at all under Vista and C# in VS2005.....

Lonnie Allen Watson
rmag.blogspot.com (blog)

Login to post a reply

Server time is: 2024-06-29 04:25:46
Your offset time is: 2024-06-29 04:25:46