home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / atari / st / tech / 4729 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.6 KB
  1. Path: sparky!uunet!mcsun!corton!loria!loria.crin.fr!eker
  2. From: eker@loria.crin.fr (Steven Eker)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Re: Need fast image conversion algorithm.
  5. Message-ID: <473@muller.loria.fr>
  6. Date: 9 Sep 92 18:16:40 GMT
  7. References: <79002@ut-emx.uucp>
  8. Sender: news@news.loria.fr
  9. Organization: CRIN (CNRS) Nancy - INRIA Lorraine
  10. Lines: 67
  11.  
  12. In article <79002@ut-emx.uucp>, timg@ccwf.cc.utexas.edu (Tim Gallivan) writes:
  13. |> Hi,
  14. |> 
  15. |> Does anyone have a fast algorithm (or some code) to transform
  16. |> a packed color image into the appropriate number of color planes?
  17. |> The packed format for a 4-bit image looks like this:
  18.  
  19. [stuff deleted]
  20.  
  21. |> Maybe some hot game hacker could code this up for me to show doubters
  22. |> that there is still a useful place in the world for his kind of
  23. |> programming (just wishful thinking :-); or maybe I should announce
  24. |> a programming contest, yeah, that's it. The winner gets a free copy
  25. |> of Ghostscript!
  26.  
  27. Well the naive algorithm involves a lot of shifts which are slow
  28. on a vanilla 68k. So (off the top of my head) here is an addition based
  29. solution for the 4-bit case (for speed you always need to specialize, ie
  30. you need separate code for the 2, 8, 16,.. bit cases):
  31.  
  32. *
  33. *       Entry:
  34. *       d7      #pixels/16
  35. *       a4      address of source pixels
  36. *       a0      destination for plane 0
  37. *       a1      destination for plane 1
  38. *       a2      destination for plane 2
  39. *       a3      destination for plane 3
  40. *
  41. *       Exit:
  42. *       d0-d7/a0-a5     trashed
  43. *
  44.  
  45. next_block:
  46.         moveq   #3,d6           ; 4 words for 16 pixels
  47. next_word:
  48.         move.w  (a4)+,d4        ; get 4 pixels
  49.         moveq   #3,d5           ; 4 pixels/word
  50. next_pixel:
  51.         add.w   d4,d4           ; Addition magick
  52.         addx.w  d0,d0
  53.         add.w   d4,d4
  54.         addx.w  d1,d1
  55.         add.w   d4,d4
  56.         addx.w  d2,d2
  57.         add.w   d4,d4
  58.         addx.w  d3,d3
  59.         dbra    d5,next_pixel
  60.         dbra    d6,next_word
  61.         move.w  d0,(a0)+        ; store 1 word of each bit plane
  62.         move.w  d1,(a1)+
  63.         move.w  d2,(a2)+
  64.         move.w  d3,(a3)+
  65.         dbra    d7,next_block
  66.  
  67. To call it from C you will need some extra code at the top & bottom to
  68. save/restore regs & pull the arguments from the stack but this depends
  69. on the calling conventions of your compiler.
  70. Note that it assumes you have a multiple of 16 pixels per line so that
  71. you can have bit planes that have a whole number of words per line.
  72.  
  73. If this you too slow you can unwind the innermost loop(s). If you intend
  74. to run it on a 68030 (TT/Falcon) unwind only the innermost loop otherwise
  75. you will have a lot of cache misses (main loop would then be > 128 bytes).
  76.  
  77. Steven
  78.  
  79.