i just realized that irc would be an awesome spot to do up a multi-player LORD game. i've always wanted to do one, and this way you could make one where people could play in real-time. err.. isn't that what a MUD is? oops ;)
TODDLER PICK GAME
caleb plays a game at fisher-price.com where you just have to put the mouse on a picture and click on it. you hear the sound of an animal, and they pop two animals on the screen and you pick the animal that makes that sound.
i can make a game like that super easy, no doubt about it. however, there's some things that i'm going to need to know how to do - that i don't know. if i were to use simple PictureBox objects, i don't know how to extract individual pixel information, and i don't know how to tell a PictureBox to not draw a certain color - for drawing sprites.
so now what we want to do is add, into Main, some routines that will check for a joystick disconnect and try to get it back. as it sits, the application drops if there's no joystick connected at the start of the program. what i'm going to do now is add stuff from GetData() in the sample right into Main and affect the drawing of the disconnect PictureBox. [working]
well, shit. i don't get this. no matter how i code this i can't seem to get that damned disconnect symbol to appear. every way that seems correct doesn't do it. its close - if you minimize and then restore it, it shows up. i thought maybe Refresh() would help, but doing it on mainForm doesn't work, nor does it work if i call it for the disconnectedPictureBox. i'm not sure what to do about this. invalidate the window? ... [working]
i think its a problem that we're trying to Hide() right after the call to Acquire() because if we don't get the joystick, i'm assuming we fire an exception which gets caught. but i don't really know what happens if it doesn't acquire it right away. [researching] i put a MessageBox in the exception handler for Acquire(), and it didn't fire when i unplugged the joy. so how do we know when we get the joystick back? >:( [working]
ok, that's whacked. if you unplug the joystick, its not catching any exceptions - none are being thrown! its not until you switch away from the app taht it realizes something's not right. hmm. so we can't tell right away that the joystick isn't hooked in :( maybe we need to continually enumerate and count? lets try that. [working] yeah, that did it. it doesn't tell us which joystick has been unplugged, though - perhaps we need to unacquire and re-acquire in the case where we have more than one joystick going. that takes us back to what i was saying the other day. if we enumerated four joysticks and then unplugged them and plugged them back in in the opposite order and tried to re-enumerate, what would happen?
anyways, for this simple sample, the method works. i'm not sure if its pretty or not, it might be slow as molasses on a cold kanadia-an day, i'm not sure. we'll find out when we start getting some timing going in here. [working]
ok, i switched around a little bit of stuff. for one, i've taken InitDirectDraw right out of the main loop. its being called by CheckJoystick. CheckJoystick enumerates all attached game devices and gets a count; if the count is less than 1, then there's a problem. in the call to InitDirectDraw, i added a != null test at the start; if we've already got a device created, then we don't need to get another.
thinking on that last bit, though.. what if i attached a different game device? shouldn't i go through again and get the new joystick? in a multi-joystick situation, we'd want to test each 'found' joystick in the enumeration against the ones we think we have, and unacquire the ones we don't have.. in this situation though, we have two ps2 adapters that will both work exactly the same. we don't need to unacquire and wait for the new joystick to be hooked in, because we know we're going to be getting the same device type back. at least i guess this shows that i'm thinking... [gone]