i need to remind myself again about what my needs are. i was going to try to imagine a full wrapper for any need i might have in the future - but why would i do that when i don't even have this done yet? only when i have it done can i know what more i'm going to need.
right now, we're going to need to add a function that will let us check to see if the joystick is still connected. we're going to repeatedly call it in the main loop. thats all we care about testing for now. [away]
i'm gonna research that right now. [working] it looks like the first try/catch block in GetData from the joystick sample has everything we need. in fact, we could probably get away with .. wait, no. i want to move a bunch of the junk (or all of it) from InitDirectInput to the spot where we 'test for a valid device', because i think that if we don't have a valid device, we might need to do all of that again to get the joystick back. but then, i'm not sure. i should probably stick to what's there and figure out where it's lacking and what needs to be done to get my desired result.
from what i see, the sample tries to poll data out of the joystick. if it can't, an exception occurs and it tries to figure out what to do about them. if NotAcquiredException or InputLostException is the case, it tries to Acquire() the josytick again.
it looks like the sample doesn't deal with the joystick if it is plugged in after the sample starts. let's see what we get if we stress the sample. [testing] ok, if the jostick isn't plugged in when we start the sample, InitDirectDraw bombs and we automatically Close() - ending the program. [testing] if you unplug the joystick while the sample runs, it catches the exception thrown and just keeps on trying to re-Acquire() the joystick until it gets it back.
since the sample just drops out if there's no joystick hooked up, we need to deal with that - because we want to run the program regardless of whether a joystick is hooked or not. we're probably going to have to move some stuff out of InitDirectDraw and into GetData (or wherever we're going to do the stuff in it) at the start, where we test for the joystick being null. i honestly can't see how that could ever be true.. if we lost the joystick for whatever reason, we should still be pointing at a device, right? even if the device is disconnected, it isn't going to be null... or is it? i'll have to bear this in mind. for now we can only have a properly working app if the joystick is hooked at the start.
i'm going to compile the sample seperately and see what happens when we take out the null== line from GetData(). [working] as i expected, the null== line at the start of GetData() is useless. if you get to that function, the app didn't drop out, and has to have a valid joystick; whether or not it lost it at some point is another story.
my next question is how does the di manager handle hooking up more than one joystick while a program is running? suppose we were expecting to have two. if the app was allowed to start if no joysticks were present, and checked for new joys being connected.. we have two different joysticks, one is an original ps2 dual shock, and the other is a microcon that fits into jenn's hands better than the original did. suppose when we had them hooked up and started the app that the original joy was player1 and her joy was player2. now imagine we unhook the joysticks and start the app up again. the input manager is going to be forced to watch for new josyticks being hooked into the system. what happens when you hook up the joysticks in different orders, or to different usb ports in the same order? these questions, and more, will have to be answered in another episode. for now, sleepy time. [gone]
