home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / apollo / 3102 < prev    next >
Encoding:
Text File  |  1992-07-23  |  4.3 KB  |  108 lines
  1. Newsgroups: comp.sys.apollo
  2. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!dododge
  3. From: dododge@wam.umd.edu (David O. Dodge)
  4. Subject: Re: Favourite DOMAIN/OS features (or mis-features)
  5. Message-ID: <1992Jul24.091811.11665@wam.umd.edu>
  6. Sender: usenet@wam.umd.edu (USENET News system)
  7. Nntp-Posting-Host: rac2.wam.umd.edu
  8. Organization: University of Maryland, College Park
  9. References: <Brozvu.5uu@apollo.hp.com> <1992Jul22.063333.4659@wam.umd.edu> <BrsrGA.DL8@apollo.hp.com>
  10. Date: Fri, 24 Jul 1992 09:18:11 GMT
  11. Lines: 95
  12.  
  13. In article <BrsrGA.DL8@apollo.hp.com> ganek@apollo.hp.com (Dan Ganek) writes:
  14. >>
  15. >>The problem is that gpr_$cond_event_wait will return a gpr_$no_event
  16. >>even when there is still mouse information in the buffer. Graphics-intensive
  17. >>programs such as Star Wars therefore have the response to mouse input
  18. >>lagging behind the actual mouse movements. The program believes that it
  19. >
  20. >First, where can I get a copy of the program? For investigation purpose
  21. >only, of course :-)
  22.  
  23. It used to be in the Adus/Iworks library (iworks.ecn.uiowa.edu or something
  24. like that). Written in Fortran, and you can create your own data files for
  25. tower and trench patterns Very faithful to the original game (IMO). This
  26. is the same guy that wrote BZONE.
  27.  
  28. >Second, keeping in mind that I haven't seen the code nor do I have ANY
  29. >idea of the expertise of the author, but this sound like the classic 
  30. >mistake that EVERYONE seems to make when first using eventcounts. (Yours
  31. >truely included). i.e.
  32.  
  33. Well I didn't even bother with eventcounts in my code :-)
  34.  
  35. >instead of the correct sequence, or some CYCLIC variation thereof
  36.  
  37. [ example deleted ]
  38.  
  39. >the programmer uses something like::
  40.  
  41. [ other example deleted ]
  42.  
  43. These examples look a little like event-based programming, which is sort of
  44. the exact opposite of what I'm trying to do. Instead of waiting for things
  45. to happen and acting on every event, I just want to poll the mouse every
  46. now and then and get its current state. I haven't looked over Revenaugh's
  47. code to see how he did things, but I'll hazard a guess he worked in almost
  48. the same way.
  49.  
  50. Here's the mouse code that I use (written several years ago). What this
  51. is supposed to do is that if you call gpx_read_mouse() the mouse state
  52. variables (gpx_bttn1-bttn4, gpx_xpos, gpx_ypos) will be set to the current
  53. state of the mouse itself. This is supposed to gather all queued events
  54. since the last invocation of this routine.
  55.  
  56. void gpx_read_mouse()
  57. {
  58.       register gpr_$event_t    et;
  59.       register char            ed;
  60.       long                     patn;
  61.       gpr_$raster_op_array_t   rops;
  62.       short                    actv;
  63.       static gpr_$position_t   pos;
  64.       long                     orig;
  65.       status_$t                gpx_stat;
  66.  
  67.       do{
  68.            do{
  69.                 gpr_$cond_event_wait(et,ed,pos,gpx_stat);
  70.            }while(!((et==gpr_$no_event)||(et==gpr_$buttons)));
  71.  
  72.            if(et==gpr_$buttons)
  73.                 switch(ed)
  74.                 {
  75.                      case 'A': gpx_bttn1=0; break;
  76.                      case 'B': gpx_bttn2=0; break;
  77.                      case 'C': gpx_bttn3=0; break;
  78.                      case 'D': gpx_bttn4=0; break;
  79.                      case 'a': gpx_bttn1=1; break;
  80.                      case 'b': gpx_bttn2=1; break;
  81.                      case 'c': gpx_bttn3=1; break;
  82.                      case 'd': gpx_bttn4=1; break;
  83.                 }
  84.       }while(et!=gpr_$no_event);
  85.  
  86.       gpr_$inq_cursor(patn,rops,actv,pos,orig,gpx_stat);
  87.       gpx_xpos=pos.x_coord;
  88.       gpx_ypos=pos.y_coord;
  89. }
  90.  
  91. >On slower machines or machines with less memory , i.e. a 580,
  92. >the probability of queueing an event is significantly less. 
  93.  
  94. One of the strange things is that the delay I get is consistent for
  95. any particular program. That is, even if I don't touch the mouse (and
  96. therefore shouldn't be sending any events) the program never catches up
  97. and always stays the exact same amount of time behind the mouse.
  98.  
  99. Keyboard input is handled the same way -- If I hit ^Q to stop a program
  100. it takes the same amount of time for the system to catch this as it
  101. does for my program to catch the mouse events.
  102.  
  103. For different programs this delay is different lengths -- it seems
  104. to be linked to the amount of time it takes for the program to generate
  105. the next frame of animation.
  106.  
  107.                                         -Dave Dodge/dododge@wam.umd.edu
  108.