home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 21327 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  2.2 KB
  1. Path: sparky!uunet!usc!cs.utexas.edu!sun-barr!olivea!apple!goofy!kip-56.apple.com!chris_russo
  2. From: chris_russo@gateway.qm.apple.com (Christopher Russo)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Fast copies from offscreen buffer to screen.
  5. Message-ID: <34529@goofy.apple.COM>
  6. Date: 13 Jan 93 00:38:33 GMT
  7. References: <1993Jan10.031829.25011@samba.oit.unc.edu>
  8. Sender: usenet@goofy.apple.COM
  9. Organization: Apple
  10. Lines: 32
  11.  
  12. In article <1993Jan10.031829.25011@samba.oit.unc.edu> Michael Kohne, 
  13. Michael.Kohne@launchpad.unc.edu writes:
  14. >I am currently involved with a friend of mine in writing a game. The
  15. >intent is for the game to be in full-color, and so we need a fast way to 
  16. >copy large off-screen pixmaps to the screen. We've tried using copybits
  17. >(making sure to setup the offscreen ports with the same color table and
  18. >ctseed as the screen), but that has proven too slow for our uses. I've had
  19. >a go at writing my own fixed-depth copybits, but I've not yet found a way
  20. >to get it much faster than copybits is (on small images, my overhead is
  21. >so much lower that I beat copybits by a mile, but on screen-sized images
  22. >my stuff is only slightly better than copybits).
  23.  
  24. Some things off the top of my head: 
  25. - Try to keep both images a multiple of 4 bytes so that you're moving all longs.
  26. - Make sure that your images offscreen and onscreen are on longword boundaries.
  27. - Use large chunks of MOVEM.L d0-d7, (a0)+ to move the image.  If possible, try
  28. to make your loop as large as possible (do as many MOVEM's as you can before you 
  29. test for the end of the line.).  This'll reduce your flexibility when it comes to variable 
  30. image sizes, but it will speed things up.
  31.  
  32.  
  33. >Currently we are considering a 'dirty-rectangles' system, however, it is
  34. >likely that most of the screen will change on each frame (lots of moving
  35. >objects.) I know this sort of thing IS possible, I own hellcats over the 
  36. >pacific and it looks like it's updating the whole screen each frame.
  37.  
  38. I haven't seen hellcats, and I've never actually written a flight simulator, but I'd 
  39. guess that games that draw large single-colored polygonal areas benefit 
  40. tremendously from not having to read in a bit image.
  41. -----Christopher Russo
  42. ----- I admire a clever .sig message.  Wish I had one. <sigh>
  43. ----- day 408.974.6070
  44.