Sorry your browser is not supported!

Hi.

Where DBPro will tell you that you've placed "make object cube 1,1" wrongly in a loop, GDK won't tell you.

Also, when you try to load an object but it's miss-spelled, DBpro tells you, but GDK won't. (it just doesn't load the object).

Finally, if you mistakenly textured an object before creating one, DBpro tells you, GDK won't.

I assume other cases.


Therefore, in this env, how do we detect such problems without hassle in GDK?

Thanks.

You should check to see if a file exists before passing it to either DBPro, or GDK...its just a good programming practice in any situation where you pass a file name to a function.

Use dbObjectExist(objnum) to see if the object exists after trying to create it. That works for objects.

Many functions in the Basic3D section return nothing at all (i.e. void).

There is a function to get the pointer for the sObject [sObject* dbGetObject(int objnum)], and you could tell alot by driving down that road, but...just use dbObjectExist to verify that it exists. That fixes all of those problems. While you are at it, why not just have a variable that says the object is valid? It is faster to compare a variable's value than to make a function call.

That's one of the things that bothered me when I looked at many of the functions. Many that returned void (no return value of any type) could have returned at least a boolean to indicate if the operation succeeded or failed. In the case of file operations I would expect I'll need to put a try/catch block around potential places where the system may throw an exception. It would probably be prudent to look to looking at exceptions if there's a chance that the system could run out of memory. But exception/error handling is a bit advanced for the beginning C/C++/C# programmer.

At present it looks like the only recourse is to be very careful what you do and where you put your files.

The DBO loading code does check to see if a file exists, and it returns false to the calling code. In that case the object will not be made, and dbObjectExist would return false, so it is traceable, but you have to let it go through all the steps first, since object creation can fail in alot of different places, for alot of different reasons.

If you want to see if the file exists, call dbFileExist You will have the same exception level that GDK has, in that case.

You could break it up a little...



...or something like that.

Or just don't make mistakes.... LOL

Seriously - This is why I made a oop wrapper... basically I have functions that DO return true or false in many cases... my Loadobject function checks if the file exists FIRST, and returns false if it doesn't... if it exists...it loads it...

Also... things like saving a bitmap doesn't' work if the file exists, so I look if it exists, delete it if it does, and I check if it exists AGAIN to see if its write protected (by still being there) and if it STILL exists, I return false, otherwise I continue with the save....

But you have to rememebr that a ton of error checking and stuff is just bloat - we are talking a video game thing right? TRY to just get it right - and keep the error checking to a minimum... mostly for development ... not for final release... I mean... FAST LEAN CODE sometimes means throwing some caution to the wind... What's your GAME gonna do? Tell the user there is an error in the LogoSpash Class in the LOAD virtual Function because file XXXX is missing? No! You make it work - or die. MAYBE dump a little a text log somewhere in case you have paying customers who want answers... then its good to have such a file so you can retort - "Well Sir, it would have worked if you didn't try to HACK my game - you deleted my logo and replaced it with your own you POSER!"

LOL Good Luck Man!

I abhor checking to but do it when it's necessary. And you're right, when writing a game and distributing it, you should have control over what's installed and what and where everything is expected to be.

My main problem with working in this kind of environment is that pop up windows indicating the error are pretty much up to you to write. They may not be necessary during game execution but they're a lot of help during the debugging stage.

Agreed!

(So is having a class that just spits out a line of text or two per "issue" that you can review when the code isn't running.)

Seems with games in particular... a breakpoint in the debugger isn't enough - you need things to be just so before you're in the "sweet spot" where the bug might be trappable or whatever.

Ideally - having #define statements set up it include or not include stuff for release stellar!

I haven't got around to such things as yet. I use a lot of dbPrint... and in one case, I made a double linked list - that I filled with errors like a log file, but then displayed the contents of this linked list in the main game loop... that was a neat thing that helped alot.