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.

DarkBASIC Discussion / colDet compatibility problems

Author
Message
Fluffy Rabbit
User Banned
Posted: 19th Feb 2013 16:31
Link
Dark Survival 2 uses Latch's colDet wrapper for its collision checking. Unfortunately, for some people the program crashes. This does not happen for me, nor does it happen for certain others, but for some, this is what the error message looks like:



I have to imagine that this happens because one of the libraries was compiled with Visual Studio and the necessary runtimes are only present on some computers. Perhaps I'm wrong, though. I would really like my game to be compatible with all of the machines that DarkBASIC can run on. Latch, could you help me out here? DS2 link
Back to top
Profile
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 20th Feb 2013 01:01
Link
That would make sense to me, that some don't have the necessary runtime libraries. Are those same individuals able to run other DB programs?

"You're all wrong. You're all idiots." ~Fluffy Rabbit
Back to top
Profile PM Email Website
Fluffy Rabbit
User Banned
Posted: 20th Feb 2013 02:31
Link
Quote: "Are those same individuals able to run other DB programs?"

Yes.
Back to top
Profile
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 20th Feb 2013 05:56
Link
@Fluffy

I'm not exactly sure what you mean by runtime libraries but if I recall correctly, I compiled both the main coldet.dll and my helper dll using Mingw GCC version 3.4.2. As far as Windows library dependencies, coldet.dll uses KERNEL32.DLL and MSVCRT.DLL and dbcwithcoldet.dll of course relies on coldet.dll whic of course has ties to kernel32.dll and msvcrt.dll. So there's really nothing kooky going on.

Your error message:



is specifically referring to the CALL DLL command. The P1, P2 etc. are return values that describe what the error is and what it's relating to or when it was stopped in the process - however, I don't know what the return values for those fields are. If I were to guess, based on behavior I've seen with coldet, it is that coldet.dll cannot be found and therefore cannot be referenced properly by dbcwithcoldet.dll. They may not be residing in the same directory or there could be a weird permissions thing going on.

LBFN was erroring out constantly on the DB noob project until I sent him a download with a specific directory structure and the most up to date coldet (which is in the coldet thread). It also contained code to call coldet functions. He no longer gets any errors.

So, unfortunately, there's no easy answer. It could be how the functions are being called, it could be the relationship between the two dlls, it could be improper use of of the library. My best guess is that dbcwithcoldet.dll can't find coldet.dll or the correct version of it to which it is paired.

Enjoy your day.
Back to top
Profile PM
Fluffy Rabbit
User Banned
Posted: 20th Feb 2013 09:37 Edited at: 20th Feb 2013 17:58
Link
@Latch-

Quote: "is specifically referring to the CALL DLL command."

Quote: "They may not be residing in the same directory or there could be a weird permissions thing going on."


The problem could be that I put the libraries in a subfolder. As far as I know, I'm not supposed to do that, but it wasn't having any problems on my machine, so I didn't worry about it. I think I should send it to the people who were having problems once I move the libraries to the root directory.

EDIT: OK, I switched the DLLs to the root directory. I encourage anyone who had problems running DS2 before to download the latest version here. (link removed) I'm still not sure if the problem is solved, though.
Back to top
Profile
Fluffy Rabbit
User Banned
Posted: 20th Feb 2013 17:54
Link
No! It doesn't work! If not the location of the DLLs, what could the problem be?
Back to top
Profile
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 20th Feb 2013 18:54
Link
I'm not really sure. A test might be to have a bare bones program that only loads the collision dll(s) and has the #include for the library. Then have it call the initialize function. See if that causes an exception. You'll need the basic setup for the memblocks and the needed arrays of course.

Speaking of memblocks, perhaps the other computers are having some kind of memory allocation problem because the initalize call reserves a chunk of memory to store all the collision information for however many objects you initialize for. If left at zero, it'll initialize 65535 collision objects for use.

Enjoy your day.
Back to top
Profile PM
Fluffy Rabbit
User Banned
Posted: 20th Feb 2013 20:52 Edited at: 21st Feb 2013 00:10
Link
Well, I tried updating the wrapper library as well as reducing the number of objects allocated to 256.

EDIT: It works! Everything is fine now. Thank you.
Back to top
Profile
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 22nd Feb 2013 20:41
Link
Good! Hopefully it's just a matter of updating and no sneaky errors will creep back in.

Enjoy your day.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-11-21 12:09:07
Your offset time is: 2024-11-21 12:09:07