From: dododge@wam.umd.edu (David O. Dodge)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: University of Maryland, College Park
Date: Fri, 24 Jul 1992 09:18:11 GMT

In article <BrsrGA.DL8@apollo.hp.com> ganek@apollo.hp.com (Dan Ganek) writes:
>>
>>The problem is that gpr_$cond_event_wait will return a gpr_$no_event
>>even when there is still mouse information in the buffer. Graphics-intensive
>>programs such as Star Wars therefore have the response to mouse input
>>lagging behind the actual mouse movements. The program believes that it
>
>First, where can I get a copy of the program? For investigation purpose
>only, of course :-)

It used to be in the Adus/Iworks library (iworks.ecn.uiowa.edu or something
like that). Written in Fortran, and you can create your own data files for
tower and trench patterns Very faithful to the original game (IMO). This
is the same guy that wrote BZONE.

>Second, keeping in mind that I haven't seen the code nor do I have ANY
>idea of the expertise of the author, but this sound like the classic 
>mistake that EVERYONE seems to make when first using eventcounts. (Yours
>truely included). i.e.

Well I didn't even bother with eventcounts in my code :-)

>instead of the correct sequence, or some CYCLIC variation thereof

[ example deleted ]

>the programmer uses something like::

[ other example deleted ]

These examples look a little like event-based programming, which is sort of
the exact opposite of what I'm trying to do. Instead of waiting for things
to happen and acting on every event, I just want to poll the mouse every
now and then and get its current state. I haven't looked over Revenaugh's
code to see how he did things, but I'll hazard a guess he worked in almost
the same way.

Here's the mouse code that I use (written several years ago). What this
is supposed to do is that if you call gpx_read_mouse() the mouse state
variables (gpx_bttn1-bttn4, gpx_xpos, gpx_ypos) will be set to the current
state of the mouse itself. This is supposed to gather all queued events
since the last invocation of this routine.

void gpx_read_mouse()
{
      register gpr_$event_t    et;
      register char            ed;
      long                     patn;
      gpr_$raster_op_array_t   rops;
      short                    actv;
      static gpr_$position_t   pos;
      long                     orig;
      status_$t                gpx_stat;

      do{
           do{
                gpr_$cond_event_wait(et,ed,pos,gpx_stat);
           }while(!((et==gpr_$no_event)||(et==gpr_$buttons)));

           if(et==gpr_$buttons)
                switch(ed)
                {
                     case 'A': gpx_bttn1=0; break;
                     case 'B': gpx_bttn2=0; break;
                     case 'C': gpx_bttn3=0; break;
                     case 'D': gpx_bttn4=0; break;
                     case 'a': gpx_bttn1=1; break;
                     case 'b': gpx_bttn2=1; break;
                     case 'c': gpx_bttn3=1; break;
                     case 'd': gpx_bttn4=1; break;
                }
      }while(et!=gpr_$no_event);

      gpr_$inq_cursor(patn,rops,actv,pos,orig,gpx_stat);
      gpx_xpos=pos.x_coord;
      gpx_ypos=pos.y_coord;
}

>On slower machines or machines with less memory , i.e. a 580,
>the probability of queueing an event is significantly less. 

One of the strange things is that the delay I get is consistent for
any particular program. That is, even if I don't touch the mouse (and
therefore shouldn't be sending any events) the program never catches up
and always stays the exact same amount of time behind the mouse.

Keyboard input is handled the same way -- If I hit ^Q to stop a program
it takes the same amount of time for the system to catch this as it
does for my program to catch the mouse events.

For different programs this delay is different lengths -- it seems
to be linked to the amount of time it takes for the program to generate
the next frame of animation.

                                        -Dave Dodge/dododge@wam.umd.edu
Newsgroups: comp.sys.apollo