home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / atari / st / tech / 4589 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.8 KB  |  77 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!decwrl!pa.dec.com!decprl!decprl!amos
  3. From: amos@prl.dec.com (Samos)
  4. Subject: The ultimate sprite routine, Generated code and the other one..
  5. Message-ID: <1992Aug27.083319.11106@prl.dec.com>
  6. Sender: amos@prl.dec.com (Amos Rosenberg)
  7. Nntp-Posting-Host: prl341.prl.dec.com
  8. Organization: Digital Equipment Corporation - Paris Research Laboratory
  9. Date: Thu, 27 Aug 1992 08:33:19 GMT
  10. Lines: 65
  11.  
  12. For color monitors (4 bit-plans)
  13.  
  14. Less memory :
  15.  
  16. In fact, the best routine before the generated code was the preshifted one, but
  17. I've got an optimisation :
  18. Let's say you preshift 16 times a sprite, and also the masks. 
  19. For the masks, you should also have twice the same mask for 8 bytes, (so a mask would take
  20. 4 bytes instead of 2..)
  21.  
  22. The routine would go like this :
  23.     lea mask_predecal,a0
  24.     lea Sprite_predecal,a1
  25.     lea Screen_address,a2
  26.  
  27.     you have the x and y, in d0-d1
  28.     so y*160 + (x >> 4) << 3 for the screen offset, and (x && 15) for the sprtie decal pointer.
  29.  
  30.     then x*sprite_size to point on the sprite shifted at (x && 15) position, + a1
  31.  
  32.     then movem.l d1-dx/a3-ax (x for left registers you have)
  33.     move.l (a0)+,d0
  34.     and.l d0,(a1)
  35.     or.l d1,(a1)+
  36.     and.l d0,(a1)
  37.     or.l d2,(a1)+
  38.     ... for the sprite size .
  39.  So here, you have optimized and with the movem, and with the double masks..
  40.  
  41.  
  42.  
  43.  Generated code, the best, but it takes a lot of memory:
  44.  
  45. Let's imagine the sprite. If you poke as warwick@cs.uq.oz.au (Warwick Allison) said,
  46. directly the code at the screen with the masks like :
  47.     and.l    #xxx,y(a0)
  48.     or.l    #www,y(a0)
  49.      ...
  50.  
  51. And if you generate this code, instead of typing all the xxx yyy zzz too many times..
  52. you generate the and.l #xxx,y(a0) in memory (I do not remember how it is exactly coded..),
  53. then you would have to jump in the address where the sprite is printed !
  54. So you make a routine that looks at the sprite, and generate and.l and or.l, and shifts
  55. the sprites, then you look at the x offset and just jump in the routine you have made in
  56. the beginning of the program. Now, the other advantage, is that when you see that the sprite
  57. has 16 black pixels, as it is a sprite, you generally and.l #$ffff,(a0) or.l #0,(a0)
  58. so here you do not and anything and just increments a0 ! you save precious cycles..
  59. If you want to push the routine as its best optimization, in your routine at the begging
  60. you redraw the sprites : try to see the 4 colors that appear the more in the sprite, and
  61. put them on different plans, the other colors on the 11 left colors, then you would often
  62. have only to or.l 1 plan (but still masking 4) because the color is always in his 16 pix. blocks.
  63.  
  64. By re-reading me, it looks very confused. If you want more information about generated code, or
  65. a source, just ask it..
  66.  
  67.  
  68. The results are : on a 8Mhz STf, 20 32*32 sprites in 1 VBL ! or huge sprites.. very cool
  69.  
  70. Amos. 
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.