home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / amiga / programm / 12832 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!swrinde!elroy.jpl.nasa.gov!jato!jdickson
  2. From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: gameport device vs. input device
  5. Message-ID: <1992Aug28.211858.3001@jato.jpl.nasa.gov>
  6. Date: 28 Aug 92 21:18:58 GMT
  7. References: <1992Aug28.174032.4126@galileo.cc.rochester.edu> <1992Aug28.182725.1768@jato.jpl.nasa.gov> <1992Aug28.203427.9520@galileo.cc.rochester.edu>
  8. Organization: Jet Propulsion Laboratory
  9. Lines: 50
  10.  
  11. In article <1992Aug28.203427.9520@galileo.cc.rochester.edu> rjw@merlin.cvs.rochester.edu (Robert Wilson) writes:
  12. >In article <1992Aug28.182725.1768@jato.jpl.nasa.gov> jdickson@jato.jpl.nasa.gov (Jeff Dickson) writes:
  13. >>In article <1992Aug28.174032.4126@galileo.cc.rochester.edu> rjw@merlin.cvs.rochester.edu (Robert Wilson) writes:
  14. >>>I'm trying to use the input device to pick up character input, and the 
  15. >>>gameport device to pick up mouse input from both ports.  This is for a 
  16. >>>psych. experiment, so the gameports have to be on equal standing: hence
  17. >>>my need for using the gameport device.
  18. >>>
  19. >>>** My question: is it possible to make the input device unaware of the 
  20. >>>gameports?  I want all mouse events to go the gameport device, and only
  21. >>>to the gameport device.
  22. >>
  23. >>The input device task opens the gameport device when it begins and packages
  24. >>any and all mouse events that occur into IECLASS_RAWMOUSE input events. Key-
  25. >>board activity too causes IECLASS_RAWKEY input events to be generated. You
  26. >>can become a handler of the input device chain (See the RKM Libraries and
  27. >>Devices chapter on the Input Device).  As far an equal standing goes, they're
  28. >>both packaged as input events and you can see them in the order they occurred.
  29. >
  30. >Thank you for the prompt reply.  I have code already that handles the mouse
  31. >via the input device, but as far as I can tell (having read the sections you
  32. >mentioned) the input device only picks up events from one port at a time.
  33. >This means that the data flows as follows:
  34. >
  35. >GAMEPORT 0: mouse->gameport dev 0->input dev->my program
  36. >GAMEPORT 1: mouse->gameport dev 1->my program
  37. >
  38. >Things I'm afraid may slow down my processing an event on gameport 0:
  39. >    1) the event being queued behind non-mouse events
  40. >    2) the input device taking a while to process the event
  41. >
  42. >I need millisecond accuracy.  If anyone can tell me that the input device won't
  43. >slow things down that much, I'll be happy to go on; but right now it seems that
  44. >data from gameport 1 could go processed faster than data from gameport 0.
  45. >
  46. >If anyone can tell me how to get around the input device, or show that my
  47. >fears are unfounded, I'd really appreciate it.
  48. >
  49. >-Robert
  50. > rjw@cvs.rochester.edu
  51.  
  52.     I can't imagine that the delays incurred by the input device
  53. processing mouse and keyboard events would be so great on a more-less
  54. dry system (nothing going on) to have unruley effects on the accuracy.
  55. Also, the input device task runs at a fairly high priority. This gives
  56. it an edge over typical stuff (i.e. Shells). Filesystems too run at a
  57. high priority, so maintaining this accuracy might be a problem if too
  58. much DOS activity is drummed up in the interim.
  59.  
  60. jeff
  61.