home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / hardware / 1444 < prev    next >
Encoding:
Text File  |  1992-08-20  |  4.5 KB  |  110 lines
  1. Newsgroups: comp.sys.next.hardware
  2. Path: sparky!uunet!caen!hellgate.utah.edu!fcom.cc.utah.edu!news
  3. From: burchard@horizon.math.utah.edu (Paul Burchard)
  4. Subject: Re: video flicker
  5. Message-ID: <1992Aug20.174209.27087@fcom.cc.utah.edu>
  6. Followup-To: comp.sys.next.programmer
  7. Sender: news@fcom.cc.utah.edu
  8. Organization: University of Utah Computer Center
  9. References: <1992Aug20.133400.21569@ppgfr.uucp>
  10. Date: Thu, 20 Aug 92 17:42:09 GMT
  11. Lines: 97
  12.  
  13. In article <1992Aug20.133400.21569@ppgfr.uucp> wolpert@mars (Florian Wolpert)  
  14. writes:
  15. > rabjab@golem.ucsd.edu (Jeff Bytof) writes:
  16. > : I wrote a short program to send image files to the
  17. > : screen in real time for animation purposes.  It works great except
  18. > : there is some flickering of the image.  Perhaps not being synched with
  19. > : the natural refresh rate of the screen is causing the flickering.
  20. > : Is there a register I should poll for the event of screen refresh?
  21. > 
  22. > Yes, this would be of interest for me too. Is there something like
  23. > a vsync-call (or is this a general problem of no-realtime-
  24. > no-singletask-unix) ?
  25.  
  26. This discussion belongs in comp.sys.next.programmer.
  27. It has NOTHING to do with low-level hardware issues---you just
  28. need to use the software capabilities NeXT has provided, such as
  29. NXImage compositing and flushWindow control.
  30.  
  31. Here are some articles on this forwarded from c.s.n.p (please direct
  32. all further discussion there.
  33.  
  34. PB
  35.  
  36. -------------------------------------------------------------------
  37. From: sam_s@NeXT.com (Sam Streeper)
  38. Subject: Re: Animating lots of small bitmaps
  39. Date: 13 Aug 92 01:20:02 GMT
  40. Sender: news@NeXT.COM
  41. Reply-To: sam_s@NeXT.com
  42.  
  43. In article <22171@venera.isi.edu> dstrout@isi.edu (David Strout) writes:
  44. > I need to animate many (up to 40) small (48>x>20) bitmaps in a view
  45. > under 3.0.  (Think what the X game netrek looks like)  
  46.  
  47. Use NXImages to store your sprites, and then lockFocus on the appropriate
  48. View or NXImage to composite them in.  Also note whether your window
  49. is retained or buffered; if it's buffered you may need to flush frequently
  50. to prevent the dirty rect from getting too big; when this happens, flushing
  51. will become slower than necessary.  If it's retained you may need to pull
  52. some tricks so that the display doesn't flicker.
  53.  
  54. For an interesting experiment, run BoinkOut from the command line like this:
  55.  
  56. BoinkOut -NXShowAllWindows
  57.  
  58. This unsupported feature will show you what how the window server is cacheing
  59. all the images an app uses, and can be very edifying.  In the case
  60. of BoinkOut, I use a retained window and buffer everything myself in an
  61. NXImage.  Once the buffer is fully constructed, I can output the changed
  62. pieces of it without worrying about accumulating a large dirty rect.
  63. (This probably won't make any sense until you program something like it)
  64. You can get BoinkOut via ftp from (nova.cc.purdue.edu) or on the 3.0
  65. NeXTSTEP release.
  66.  
  67. > I tried doing
  68. > it with a subview per bitmap, but that flashed badly.
  69.  
  70. No doubt.  Not a good approach for fast animation.
  71.  
  72. > I tried putting
  73. > them all in the drawSelf:: of the main view, but that makes the whole
  74. > view flash.  
  75.  
  76. I recommend using your own optimized animation display methods that
  77. draw as little as possible.
  78.  
  79. > Current idea is to define a Type 3 font with my bitmaps,
  80. > then use xyshow to draw them.  This seems really gross.  If I wanted
  81. > to do graphics with fonts, I'd program (pick one: X, TI99/4a, IBM PCs)
  82.  
  83. This is fast, but is a big pain, and you can only output 1 color at a time.
  84. NXImage is much more appropriate.
  85.  
  86. -sam
  87.  
  88. ---------------------------------------------------------------------------
  89. From: andrew@cubetech.com (Andrew Loewenstern)
  90. Subject: Re: Animating lots of small bitmaps
  91. Organization: Cube Technologies, Inc.
  92. Date: Wed, 12 Aug 1992 04:09:12 GMT
  93.  
  94. In article <22171@venera.isi.edu> dstrout@darpa.mil (David Strout) writes:
  95. >I need to animate many (up to 40) small (48>x>20) bitmaps in a view
  96. >under 3.0.  (Think what the X game netrek looks like)  I tried doing
  97. >it with a subview per bitmap, but that flashed badly.  I tried putting
  98. >them all in the drawSelf:: of the main view, but that makes the whole
  99. >view flash.  Current idea is to define a Type 3 font with my bitmaps,
  100. >then use xyshow to draw them.  This seems really gross.  If I wanted
  101. >to do graphics with fonts, I'd program (pick one: X, TI99/4a, IBM PCs)
  102. >etc.  Does anyone have a better method?  Ideas welcome, example code 
  103. >even better.
  104.  
  105. turning flushWindow off before drawing will hide the flashing, but
  106. compositing may be too slow...  Fonts are really fast though.
  107.  
  108.  
  109. andrew
  110.