home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / atari / st / tech / 4410 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  4.4 KB
  1. Path: sparky!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick
  2. From: warwick@cs.uq.oz.au (Warwick Allison)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Re: Sprite code (Re: Second&last time: Hacking Contest)
  5. Message-ID: <9817@uqcspe.cs.uq.oz.au>
  6. Date: 14 Aug 92 04:14:22 GMT
  7. References: <438@muller.loria.fr> <1992Aug06.184949.22119@infoserver.th-darmstadt.de> <439@muller.loria.fr> <1992Aug09.011934.47152@news.th-darmstadt.de> <440@muller.loria.fr> <9777@uqcspe.cs.uq.oz.au> <441@muller.loria.fr>
  8. Sender: news@cs.uq.oz.au
  9. Reply-To: warwick@cs.uq.oz.au
  10. Lines: 107
  11.  
  12. eker@loria.crin.fr (Steven Eker) writes:
  13. >warwick@cs.uq.oz.au (Warwick Allison) writes:
  14.  
  15. >>>Yuk! There are several good ways to handle the background. Saving on a sprite
  16. >>>by sprite basis, interleaved with drawing the sprites is not one of them.
  17. >> 
  18. >> Well, IMO, it IS the best method, for these reasons:
  19. >> 
  20. >>     1. Encapsulated (don't need some GLOBAL background map)
  21. >>     2. Allows for different update frequencies of different sprites
  22. >>     3. Memory efficient
  23. >>     4. Fast
  24.  
  25. >The real problem with this method is when sprites overlap - then doing
  26. >the right thing gets complicated & slow.
  27.  
  28. Complicated?  All you do is push them onto a stack when you draw then,
  29. and pull them off to get the wiping order.  Usually, it is sufficient
  30. to just do it with code, rather than doing it dynamically:
  31.  
  32.     while (1) {
  33.     Sprite1.Wipe();
  34.     Sprite2.Wipe();
  35.     Sprite3.Wipe();
  36.  
  37.     Sprite3.Draw();
  38.     Sprite2.Draw();
  39.     Sprite1.Draw();
  40.  
  41.     Pages->Flip();
  42.     }
  43.  
  44. >If you aren't replacing the
  45. >background thru the (possibly) shifted mask (which is slower) the
  46. >sprites don't even have to overlap - just the 32x32 (or whatever)
  47. >rectangles.  
  48.  
  49. I can't believe anyone would ever consider replacing the background
  50. through a shifted mask!
  51.  
  52. >|>     2. Keeping global background
  53. >|>         - This one is too dependent on the application to
  54. >|>           be viable as a general scheme.  For example, it
  55. >|>           works okay for a static background, but once you
  56. >|>           start animating the background, your CPU-load
  57. >|>           massively increases as you keep having to update
  58. >|>           both the display images and the backgrouind store.
  59.  
  60. >I believe STOS does this. If you have lots of sprites and comparatively little
  61. >background movement then this can win.
  62.  
  63. I believe STOS is a slow, hacky pile of sh!t...  Have you seen some of the
  64. programs written with it - ewww, chunky-slow to the max!
  65.  
  66. >How about:
  67. >    4. Wipe all sprites, Save under new positions, draw all sprites etc.
  68.  
  69. This is exactly my #1 method, except mine is encapsulated.
  70.  
  71. You are saying:
  72.     for each sprite 1..n { sprite.Wipe }
  73.     for each sprite 1..n { sprite.SaveUnder }
  74.     for each sprite 1..n { sprite.Draw }
  75.  
  76. I am saying:
  77.     for each sprite 1..n { sprite.Wipe }
  78.     for each sprite n..1 { sprite.DrawAndSaveUnder }
  79.  
  80. My method is superior, simply because I get the sprite.SaveUnder almost
  81. for free:  YOU ALREADY HAVE TO READ THE SCREEN IN ORDER TO DRAW THE SPRITE,
  82. so you may as well store that read data as you draw, saves reading twice.
  83.  
  84. >        Okay you need to double (better still triple) buffer to avoid
  85. >        flicker but its fast & you can decide on sprite priorities
  86. >        & handle overlapping sprites correctly.
  87.  
  88. Obviously you have to double buffer.  Any program that doesn't double-buffer
  89. is a hack.  (BIG smily!! -- Even Shift doesn't double-buffer - but I love it)
  90.  
  91. >IMHO the best way the handle background is dependant on the number of
  92. >sprites & the nature of the background. For this reason I prefer the
  93. >keep the "save under" code separate from the "draw sprite" code so one
  94. >can choose whether & when to use it.
  95.  
  96. While I prefer to write code that works well in the general case :-)
  97.  
  98. >Do you have seperate code for each "partly off the edge of screen"
  99. >case (actually you only have to worry about the left & right edges)?
  100. >That must multiply up to quite a bit of asm.  
  101.  
  102. Haven't had any need for a ClippedColourSprite yet.  When I do, it will
  103. only be a small matter of coding up the one sized clipped version.
  104.  
  105. Which reminds me - was this a competition?  I wrote some VERY fast 
  106. sprite routines in a furious discussion with Dave B. - 60 or so
  107. single-bitplane 16x16 sprites at arbitrary positions on an arbitrary
  108. background was I believe my limit...
  109.  
  110.  
  111.  
  112. --
  113. Warwick
  114. --
  115.   _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
  116.  /     * <-- Computer Science Department,  /  
  117.  \_.-._/     University of Queensland,    /      void (if removed)
  118.       v      Brisbane, Australia.        /  
  119.