home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / apollo / 3074 < prev    next >
Encoding:
Text File  |  1992-07-21  |  2.7 KB  |  57 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: <1992Jul22.063333.4659@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: <1992Jul19.232614.10280@mnemosyne.cs.du.edu> <1992Jul20.093747.12417@wam.umd.edu> <Brozvu.5uu@apollo.hp.com>
  10. Date: Wed, 22 Jul 1992 06:33:33 GMT
  11. Lines: 44
  12.  
  13. In article <Brozvu.5uu@apollo.hp.com> ganek@apollo.hp.com (Dan Ganek) writes:
  14. >>Misfeatures:
  15. >>
  16. >>   They changed the way the RM_$ calls work, so the program I wrote to put
  17. >>   a picture in the DM background doesn't work right anymore (this also
  18. >>   affected some of Apollo's own demo programs). RM_$ being unsupported and
  19. >>   undocumented I probably shouldn't complain too much, though :-)
  20. >
  21. >I didn't change the way the rm worked! THEY (the dm and Xapollo) people
  22. >changed the way it's used :-) At SR10 there is no longer a "background"
  23. >rectangle - use RM_$INQ_INTERIOR_VIS_LIST on the root instead of
  24. >RM_$INQ_VIS_LIST to get the exposed areas of the root.
  25.  
  26. Thanks for the tip. I'll have to dig up my old backdrop program and see
  27. how it worked (it's been a few years). The weird thing is that the way
  28. it is now it isn't consistent -- it seems to pick a window at random to
  29. throw the image/pattern into (same as the old moire demo program -- not
  30. surprising since I think that's what I used as a model for my backdrop code).
  31.  
  32. >>   Recent versions of GPR have the mouse handling screwed up. Try playing
  33. >>   "star wars" on a DN3500 to see what I mean.
  34. >                                 
  35. >HUh??? Explain, please.
  36.  
  37. The easist way to see what's going in is to play Revenaugh's Star Wars on
  38. a DN580 and then try it on a DN3500. The difference should be immediately
  39. noticable. The 3500 (and other newer models) buffer the mouse input
  40. "incorrectly".
  41.  
  42. The problem is that gpr_$cond_event_wait will return a gpr_$no_event
  43. even when there is still mouse information in the buffer. Graphics-intensive
  44. programs such as Star Wars therefore have the response to mouse input
  45. lagging behind the actual mouse movements. The program believes that it
  46. is keeping up because GPR tells it that it has read all the events off
  47. the queue.
  48.  
  49. The more graphics work the program is doing, the longer the delay. I
  50. have some animation-style programs that delay several *SECONDS*.
  51.  
  52. This has been a problem for quite some time now. It's not usually
  53. something you worry about, but with game programs it makes them kind of
  54. difficult to play :-).
  55.  
  56.                                            -Dave Dodge/dododge@wam.umd.edu
  57.