🚀 go-pugleaf

                   ** SPRITE ENGINE NEWS, VOL #2 **

1) New idea for the sprite engine queue by Robert Baruch.
He writes:

"But anyway, the more I mull over the architeture I sent you, the more I like
it... 
ED:  You're so modest, Rob! :)
"For example, to write sprites quickly, we can use registers and counters.
We can have a Sprite X counter (SCX), Sprite Y counter (SCY), a Sprite X Begin
Register, X End, Y Begin, and Y End Resisters (SBRX, SBRY, SERX, SERY).  There
will also be a Sprite Address Counter (SAC).

For each sprite:
  Load the SAC with the sprite's beginning address.
  Load SBRX, SBRY, SERX, SERY [perhaps in parallel] for the sprite.
  Load SCX with SBRX, and SCY with SBRY (in parallel).
  Count, using SCX / SCY as the screen coordinates, and the
    SAC as the sprite pixel address.
  When SCX is equal to SERX, reload SCX with SBRX, and increment SCY.
  When SCY is equal to SERY and SCX is equal to SERX, the sprite
  has ended.  Go to the next sprite.

This can be implemented easily.  Also, we can of course have transparent
color, so that no write takes place if the byte retrieved is the 
"transparent" color."


ED: Rob, could you explain this in a little more detail please?



-----------------------------------------------------------------------------



2) Multiple backgrounds problem is SOLVED!

consider this setup:

               ----------------------------------------------------
              |                                                    |  
Background1:  |                       aa             aaa           |
              |        aaaa          aaaa          aaaaaaa         |
              |aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa|
               ----------------------------------------------------
This is like the bunch of blocks the player will walk on.  An array
of words, each letter represents the tile number of a background tile.

               ----------------------------------------------------
              |                                           bb       |  
Background2:  |   bb         bb         bb        b       bb       |
              |   bb         bb         bb        b       bb       |
              |   bb         bb         bb        b       bb       |
               ----------------------------------------------------
This is a row of trees that scrolls behind the blocks at a slower rate.
This is an array of words just like background1

               ----------------------------------------------------
              |  c ccccc       ccccc            cc      cccccc     |  
Background3:  |   ccccc      ccccccccc         cccc      cccc      |
              |                ccccc            cc                 |
              |                                                    |
               ----------------------------------------------------
This background contains cloud designs and can be very intricate.  This
is an array of words also.



The algorithm goes like this:

B1 = 0
B2 = 0
B3 = 0

for i = 0 to number of pixels to scroll do
   for y = 0 to 200 do
      for x = 0 to 320 do
       compute the byte in the particular tile from background1 using array
       pointer B1.  
       If > 0, print it and go to blah;

       compute the byte in the particular tile from background2 using array
       pointer B2.  
       If > 0 print it and go to blah;
 
       print the byte in the particular tile from background3

     blah: Increment B1, B2, B3 so that they are ready to draw
           the next row of pixels.

    end;
   end;
   B1 = i
   B2 = b1/3     /* Scroll Background2 3 times slower than Background 1 */
   B3 = b1/6     /* Scroll Background3 6 times slower than Background 1 */
end;

POTENTIAL PROBLEMS:  Computing a particular byte from a tile definiton
in relation to where the current X and Y positon is is very time consuming.  We need a streamlined way to compute a particular byte from a tile definition.
For instance, in almost all cases of drawing the background, part of a tile is 
offscreen.  Trying to find out what part of the tile definition to display and
what part NOT to display takes alot of processor time!  

EXAMPLE:
          |         
          |      Displayable part of 
          |      screen
      ____|___
     |    |   |         
     |    |___|______________
     |        |
     |        | <--Background Tile (a word, NOT a bitmap)
      --------

   If ANYONE has a streamlined way of figuring out how to compute bytes from
this setup, please let me know!!!
   

THERE IS A MULTIPLE BACKGROUND DEMO ON WUARCHIVES (128.252.135.4):
"scroldemo.zip" in the directory "pub/MSDOS_UPLOADS"



-----------------------------------------------------------------------------



3) Someone said that the sprite engine should be capable of animating water,   
  etc.  This can be done as follows:

                        ______________________________________
                       |                                      | 
                       |                                      | 
                       |              bbzzzzzbb               | 
     Background:       |              bbzzzzzbb               | 
   bb = Typical        |bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb| 
   Super mario Bros    |______________________________________|
   blocks

 1) replace zzzzzz with yyyyyy
 2) replace yyyyyy with wwwwww
 3) replace wwwwww with zzzzzz
 4) goto 1   

 zzzzzz,yyyyyy, and wwwwww all represent tile definitions of water.  By
replacing them in the tile map through software, the water will automatically 
be animated.



-----------------------------------------------------------------------------



4)  I've been getting alot of E-mail from people who want to use VGA in 
conjunction with the Sprite Engine.  Your points are well taken, but I 
personally prefer to start fresh.  The sprite engine will have nothing to do with regular VGA or SVGA and will NOT act as a genlocking device.  The sprite engine will be a complete standalone video card with its own on-board memory
for defining sprites, the background maps, and background tile definitions.
This goes against my previous theory of using DOS memory to define sprites, etc, for several people have pointed out that using DOS memory will not be fast
enough.


  Comments, additions, or corrections?  Either post them to
rec.games.programmer or mail me at:

  kennehra@logic.camp.clarkson.edu