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 Professional Discussion / Game Crashes When Controller Is Plugged After Launching

Author
Message
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 2nd Apr 2012 03:05 Edited at: 2nd Apr 2012 03:09
Hi. Does anyone know how to detect a controller that is plugged in after the game starts without:

a) Controller not being detected
b) Program freezing/crashing


I am not reading controller inputs with no device plugged in, this is purely about detecting the new device, and having the game immediately crash. (DBP ver. 1.077)

Thanks,
Example Code Below



Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 4th Apr 2012 04:12
No takers huh?

So with DB PRO the controller has to be plugged in before the program starts or you have to restart the program?


How does something like this go years without being fixed?!?

LAWL

MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 4th Apr 2012 07:26
so this is what you called asking around?

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 5th Apr 2012 04:24 Edited at: 5th Apr 2012 04:27
Absolutely. Before submitting a bug report one should thoroughly search the forums to the best of their ability for a solution.

If there is no solution then one should ask for assistance in the support forums.

If one can't get any support and the problem still looks like a genuine bug then it's helpful to everyone else to submit a bug report.

And having people show up, not even address the actual problem, and basically declare that the problem doesn't exist... like what you did in the bug report thread, isn't helping.

zeroSlave
17
Years of Service
User Offline
Joined: 13th Jun 2009
Location: Springfield
Posted: 5th Apr 2012 05:03
I messed with the code, and it doesn't crash if you put:
Sync on
Sync rate 0
at the top. However, it doesn't update the information if a controller is plugged in. Ima mess with it some more.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 5th Apr 2012 07:52
Thank you for looking into it.

When you said it wasn't crashing, I tested the code again and the crashing persisted (when inserting controller after starting the program). I then tested the controller and other DBPRO apps are working perfectly using the same detection code (only if the controller is plugged in before starting them).

I rebooted the computer (running for several days). Now the exact same code doesn't crash, but as you say still doesn't update information or detect the new controller (when inserted after the program starts).

"Sync on" and "Sync rate 0" had no meaningful impact on the behavior.

zeroSlave
17
Years of Service
User Offline
Joined: 13th Jun 2009
Location: Springfield
Posted: 5th Apr 2012 08:17
Hmm... That is odd. Now I am getting an error about 1/5 times with or without the sync. (no restarts- had computer on since 3/15/12) Seems rather inconsistent. I would assume this behavior is not intentional.

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 5th Apr 2012 08:40
Yeah that's what I'm sayin.

Todd Riggins
21
Years of Service
User Offline
Joined: 29th Oct 2004
Location: Texas, USA
Posted: 5th Apr 2012 12:48 Edited at: 5th Apr 2012 12:51
Yeah it seems like the program is going to fast for it since your program keeps calling the PERFORM CHECKLIST FOR CONTROL DEVICES command every loop resulting in the crash. For some reason I can't return a 1 with checklist value a() when I test my gamepad.

BUT, code below works for me. Instead of checking constantly, I call the Input_DefaultController() function with the spacebar.

I do agree that DBPro should not crash like that though. It should be able to handle a constant check like that. I'll take a look at the DBPro Google source code that I have and see if I can spot something quick. If I can find something I'll post the c++ code change that I did in your Bug Report thread.

Also, I noticed that we need to somehow clear the "JoyStick Information" when the user unplugs the game device. Mine keeps the same info when I unplug my gamepad and then call the Input_DefaultController() function again.



ExoDev.Com - A Game Development Tools Website! Featuring: XBOX360 CONTROLLER LIBRARY
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 5th Apr 2012 23:38 Edited at: 5th Apr 2012 23:53
Todd I tested the issue before even posting about the problem by adding SLEEP 1000 and then SLEEP 5000 into the loop instead of using a spacebar. It didn't help, so I didn't include it in the example.

Edit:
Yeah that does work. What it tells me is that if the game checks for the controller while Windows is enabling the USB device DBPro will crash.

This means that you can't automate controller detection when plugging the controller in after the game started without a risk the whole thing will crash. That is to say if the detection occurs at "a bad time". It also means that if the player has to press a button activate the detection, pressing the button too early can also by chance crash the program.


Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Apr 2012 00:33 Edited at: 6th Apr 2012 00:45
I isolated the problem into a new example using some of Todd's code. Basically you just insert the controller after the program has started.
Sometimes it works and sometimes it crashes. The bug only occurs on the first plugin of the controller.
I've introduced a small delay between controller checks which proves my previous post above. This problem may be affected by processor speed also btw, since different delay values may be needed to reveal the bug for people, since this is highly timing dependent.



Another Bug!

I discovered you can also crash the program if you by chance remove the controller when SET CONTROL DEVICE checklist string$(quantity) is executing.


EDIT: If you comment out SET CONTROL DEVICE the program will still crash if the controller is inserted at "a bad time". This proves there is a bug in PERFORM CHECKLIST FOR CONTROL DEVICES, and another bug in SET CONTROL DEVICE. Both bugs are related to the controller being in a transition state where windows is enabling or disabling the device.

MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 6th Apr 2012 12:32
why not code in a trap door?

like if devices not found exit loop.. and would it not be better to use a while instead of a constant do:loop?

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Apr 2012 22:01
No the do loop is just there for the purpose of the example.

At issue is the fact that when detecting controllers there is each a sliver of time when the controller can be in the process of being plugged in or unplugged that crashes the detection commands.

It seems to happen only on the first successful check of the device.

The commands don't properly delist unplugged devices, so it's only on the first successful check.


The end result of this is that without a bug fix, controller detection has a chance of crashing the program that you can't completely protect against.

MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 6th Apr 2012 22:18 Edited at: 6th Apr 2012 22:19
I was thinking this, and I may be correct as everytime i learned to use checklists, I learned to clear/empty the checklist POST function or after performing the check as you are trying to empty an empty checklist... try using your code with this structure instead?

the code below is the example code which comes within DBPro...

Quote: "cls
print "DISPLAY MODES"
print
perform checklist for display modes
for c=1 to checklist quantity()
width=checklist value a(c)
height=checklist value b(c)
depth=checklist value c(c)
print "found:";checklist string$(c)
next c
empty checklist
set display mode width, height, depth
if check display mode(width, height, depth)=1
print "using:";width;" ";height;" ";depth
endif
do
loop
end"


EDIT

Changed code box to quote in order to highlight EMPTY CHECKLIST

Todd Riggins
21
Years of Service
User Offline
Joined: 29th Oct 2004
Location: Texas, USA
Posted: 6th Apr 2012 22:24
Mage, In your Bug Report thread, I posted that there is indeed a problem with DBPro's C++ Source Code itself. It has nothing to do with the actual detection. Rather, it has something to do with a 'checklist' array in the C++ code getting NULL'd at the wrong time and c++ code trying to write to it which indeed gives that crash.

So, yes, it can get fix. I was able to fix the DBPro's C++ code myself and then your code worked fine. But, that's if Lee or IanM or whoever wants to fix it to be included in an update. I believe I included easy enough instructions for them to follow if they wanted to see what I did to fix it in your thread.

ExoDev.Com - A Game Development Tools Website! Featuring: XBOX360 CONTROLLER LIBRARY
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Apr 2012 22:54 Edited at: 6th Apr 2012 22:55
Thanks a million, can you post a bug report specifically for that issue then?
Not sure they'd read through all that nonsense just to discover it was a problem checklists instead.

Todd Riggins
21
Years of Service
User Offline
Joined: 29th Oct 2004
Location: Texas, USA
Posted: 7th Apr 2012 00:02
No problem man. I created a DirectInput dll library for Blitzbasic back in the day and this kind of thing interests me.

I don't think it warrants another bug report as your bug report should do just fine. After all, it's a bug report... they should read it.

I have a solution to the sound volume bug in the bug reports that me and other people have problems with that has yet to be commented on or questioned about by Lee or whoever else that officially fix's those problems. So I kind of doubt they'll just listen to me.

What I will do is compile a DBProInputDebug.dll that should fix that problem and post it to that bug report just for testing purposes. We can then see if it works for you and anybody else who would generously test it. Mabie that might help win it to be "officially fix'd". All we can do is try.

..... Because one thing I do know is that the DirectX's DirectInput.Dll itself can indeed handle constant checking/"polling" like that.

ExoDev.Com - A Game Development Tools Website! Featuring: XBOX360 CONTROLLER LIBRARY

Login to post a reply

Server time is: 2026-07-10 05:02:17
Your offset time is: 2026-07-10 05:02:17