home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / viscobv6.zip / vac22os2 / ibmcobol / samples / toolkit / mm / beehive / readme.txt < prev   
Text File  |  1996-11-19  |  3KB  |  53 lines
  1.  
  2. Sprite Compiler
  3.  
  4.  
  5. "Compiled Sprites" is an advanced programming technique used to maximize
  6. the blit performance of a two dimensional sprite. The concept is similar
  7. to the one employed by DIVE in that known parameters of the blit operation
  8. are used to generate a custom blitter that is optimized for the given
  9. parameters. In the case of DIVE, the blitter is optimized for a given
  10. source and destination image type and size. A sprite compiler would
  11. optimize the blitter further by using the actual image data to generate a
  12. blitter that is specific to that image. In the context of a game, the
  13. sprite compiler would be used to generate a small, fully optimized blitter
  14. for every sprite in the game. Each sprite could then be considered a self
  15. contained object ( a Compiled Sprite ) that would blit itself onto the
  16. destination buffer.
  17.  
  18. Where this technique becomes most valuable is when blitting irregularly
  19. shaped or partially transparent sprites. With this kind of sprite, the
  20. blitter would normally have to test each pixel of the sprite and copy it,
  21. only if it is not transparent. Processing a conditional branch instruction
  22. for every pixel in the sprite would dramatically increase the amount of
  23. time required to blit. When using a compiled sprite, the blitter already
  24. knows which pixels are transparent and adjusts the source and destination
  25. pointers accordingly.
  26.  
  27. In a PCDOS world, where the properties of the display mode are known (
  28. probably Mode 13 or Mode X ), the sprite compiler would generate a blitter
  29. that could blit the sprite directly to video memory. Under a GUI like
  30. Warp, the compiled sprite could be designed to blit to an off screen
  31. buffer, where the entire scene is rendered before being copied to the
  32. screen by DIVE ( double buffering ).
  33.  
  34.  
  35.  
  36. Beehive
  37.  
  38. The purpose of this application is to demonstrate the power of compiled
  39. sprites by comparing the performance of a typical sprite algorithm against
  40. a compiled sprite.
  41.  
  42. When the application first starts, it will display a single sprite moving
  43. in a random path around the application window. The user can add sprites
  44. by holding down the 'H' key. As the sprite count increases, the effects on
  45. the frame rate will become evident. The actual frame rate will be
  46. displayed on the title bar.
  47.  
  48. The user will be able to switch the application from compiled sprites to
  49. normal sprites from a pull down menu. As the number of sprites increases,
  50. the difference in performance from compiled to normal sprites will become
  51. more dramatic.
  52.  
  53.