Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!pepper!cmcmanis From: cmcmanis%pepper@Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga Subject: Re: How do I read the Joysticks? Message-ID: <34968@sun.uucp> Date: Fri, 27-Nov-87 16:27:01 EST Article-I.D.: sun.34968 Posted: Fri Nov 27 16:27:01 1987 Date-Received: Mon, 30-Nov-87 00:44:13 EST References: <760@hubcap.UUCP> <816@sdcc18.ucsd.EDU> <2073@umd5.umd.edu> <817@sdcc18.ucsd.EDU> Sender: news@sun.uucp Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 53 Keywords: joysticks In article <817@sdcc18.ucsd.EDU> (John Schultz) writes: >>I suppose that these people will get what they deserve eventually. > Oh, ok. Why include such a statement? Because Louis feels strongly about this issue like many others do as well. If C/A changes the hardware your program and everyone who used your example will break. They will all bitch at *Commodore* who can them point them at *you*. You will feel very put upon and irritated and Louis is implying that this is what someone who suggests such a hack deserves. > This tells us nothing new. I have plenty of written data, but my >routines are as fast, compact, and efficient as possible. Any other >method will be slower, larger, and less efficient (but my mind is >still open for a better method). One thing that you may not have considered here is that the required speed is not that great (since humans are not that fast.) Thus the device driver solution provides more than sufficient speed (although it is definitely not the fastest method), and Commodore will bend over backward to keep the machine compatible at this level because it is the "right thing" to do. If they break it *they* will get what they deserve. > I offer solutions, others submit suggestions. Why not show us your >solutions? Learn to identify the difference between a hack and a solution. A solution is valid for *all* cases by definition. One such case is that the hardware has changed, your example fails to account for that, thus it is not a solution. I'm sure by now Bob Burn's article on how to use the joystick *in all cases* has reached your site, if not send me mail and I will forward you a copy. >(Reading joydat is harmless. If anyone can *prove* otherwise I'm >all ears [not just hypothetical situations]. If the hardware is >changed, then will my programs compiled today that access joydat via >the gameport.device still work? I seem to have heard somewhere that >even that device does not follow the so-called rules) Reading joydat is harmless, but if the hardware changes your program and anyone else who used your example will break. This will not be the case if you use the gameport device. A simple way to prove this is to write your own gameport.device that talks to the parallel port (use an adapter to make your standard joystick out of it). Replace the gameport.device with SetFunction() and watch. Programs using the device interface continue to work, those useing your hack stop working. QED. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.