peck@ral.rpi.edu (Joseph Peck) (01/15/91)
I was wondering if anyone could give me a hand before I hunt down the guy at Commodore who wrote the gameport.device and commit some illegal act..... Oh wait, that goes in .advocacy. Look there for a companion article soon. I am writing a two player game, and I would like to use both gameports for joysticks. Sooooo, I look in the RKM's for some help. It says that I should check if the gameport unit is in use before I run off and change it to my desired type (absolute joystick). Well, it also says that unit 1 (the mouseport) is normally in use already as type mouse. Is there a nice way to steal the port when I run my game, and then return it when either the game is paused or quit? I tried being nasty in several different ways: Simply pretending that it is not in use and setting it to whatever I want. Checking what it is currently being used as, stuffing the new type in, and then changing it back to what it originally was when I exit. Reading the hardware directly. So far, the only thing that has worked has been reading the hardware directly. The other methods work occasionally, sometimes reading the joystick like a joystick, and other times completely ignoring the port. They do either screw up the port when the program ends, or crash the machine (one of those times it was a very pretty blue display :) I am hoping that I simply missed something in the RKM's, and that this will be easy to fix..... I am *attempting* to be multi-tasking friendly and not do anything that will trash other programs running in the background. (Geee, where's Mike Farren when you need him? I think the February BADGE meeting should be moved to Troy, NY. A possibility? :) Anyhow, thanks for your help, Joe Peck peck@ral.rpi.edu
DXB132@psuvm.psu.edu (01/16/91)
In article <`42^3D|@rpi.edu>, peck@ral.rpi.edu (Joseph Peck) says: >will be easy to fix..... I am *attempting* to be multi-tasking friendly >and not do anything that will trash other programs running in the >background. (Geee, where's Mike Farren when you need him? I think I don't see how reading the ports directly is going to "trash" other programs. Really, I think this is a case of going overboard in trying to be a friendly program. (A worthy goal, especially if it's not an arcade-type game). Kind of reminds me of the long, complicated program in AmigaMail a while back about how to toggle the LED that could have been done quite nicely with bchg #1,$bfe001 / rts. What 2.0 REALLY needs is an led.resource....:-) :-) :-) -- Dan Babcock
peck@ral.rpi.edu (Joseph Peck) (01/17/91)
In article <91015.145934DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >In article <`42^3D|@rpi.edu>, peck@ral.rpi.edu (Joseph Peck) says: > >>will be easy to fix..... I am *attempting* to be multi-tasking friendly >>and not do anything that will trash other programs running in the >>background. (Geee, where's Mike Farren when you need him? I think > >I don't see how reading the ports directly is going to "trash" other programs. >Really, I think this is a case of going overboard in trying to be a >friendly program. (A worthy goal, especially if it's not an arcade-type game). I don't really either, that was more of a general statement about my entire programming intentions. There are really two reasons why I would like to avoid reading the hardware directly. The first is that eventually, the locations of the joystick registers may be moved. (I know, its not likely, but why take a chance if you don't have to....) The second is that there are several points in the game where you make a selection using the joystick. Since we do have this neat multitasking machine, if you flip to a different screen to check on something else, I still pick up left mousebutton clicks as firebutton actions! This is really no great trauma, since it is just a game, but it would be "nice" if it didn't do this. > >Kind of reminds me of the long, complicated program in AmigaMail a while back >about how to toggle the LED that could have been done quite nicely with >bchg #1,$bfe001 / rts. What 2.0 REALLY needs is an led.resource....:-) :-) :-) > >-- Dan Babcock Joe Peck peck@ral.rpi.edu P.S. Buy lot's and lot's of my game. The more money that I make on this one, the better the next ones will be (better equipment). :) .