🚀 go-pugleaf

 
          ** To all people interested in the "Sprite Engine" **

Hi!  I've gotten a GREAT response from the idea of building a sprite engine!
I definitely want to try to get everyone together and try to build this thing!!
Who knows?  We could all become millionaires!

Here are the people who said that they'd be intrested in helping to build
a Sprite Engine:

Kevin Yoon: c579819@mizzou1.missouri.edu
Kevin is currently studying electrical and computer engineering and has some
design skills

Dan Liebgold: liebgold@seas.ucla.edu
Dan is a computer science and engineering major and showed a great deal of 
enthusiasm towards the idea!

Dave Hanley: U55870@uicvm  ** ADDRESS UNKNOWN BY UNIX MAIL SERVER **
Dave told me he is a "Demon Coder"  GREAT!  We'll need plenty of programming
help!!

Robert Baruch : baruch@nynexst.com
Robert has a great deal of hardware knowledge and access to large quanties of
data books.  He also knows of the TILE background system for the SNES and the
Genesis and Modex for the IBM VGA.

Andre A. Nurwono: andrean@cs.utexas.edu
Had good ideas concerning the implementation of the sprite engine using
libraries and pices of code, and suggested the ability of the engine to be
able to "clip" sprites.

Darren Lyon: darren@nicky.dialix.oz.au
He has access to:
- Two electronics geniuses (more if he needed them)
- Two IBM programmers (Him and a friend)
- Two Hardware programmers
- A musician, full recording setup
- A graphics artist

The people he mentioned above may be willing to dedicate time into the project,
if they set about the project in a clear direction.

He has been working on a software version of the sprite engine (like me)
and is becoming the Chairperson for the Austrailian Shareware foundation.


-------------------------------------------------------------------------------
Ok...here are my suggestions for the sprite engine:

1)  I'd make it comaptible with all IBMs (except the IBM pc jr.) from
    the lowly 8086 to the 80486...basically, if you have a card slot 
    and its an ibm, it'll run.  

2)  I'd have some scaling and rotation features for the sprites (this 
    can come later...and is just wishful thinking :)  

3)  It should be able to output to a regular VGA monitor 

4)  Definitely two atari 2600 joystick ports!!  (for those arcade style
    gamers!)  

-------------------------------------------------------------------------------
The following is information describing my ideas on building the sprite engine.
Feel free to comment on these ideas, add your own, point out errors, etc!!!


      |    YOUR COMPUTER    |
      |                     |
      |           (1) (2)   |
       ------------|---|-----
                   |   |                 ___________
Y adapter cable --> ---                 ||---------||
                     |                  ||         ||
                     |                  || Screen  ||
                     |__________________||         ||
                                        ||_________|| 
                                         -----------

(1) Is the output from a regular VGA card
(2) Is the output from the sprite engine

When you change into "Game Mode" the software turns off the VGA card and turns
on the sprite engine.  This causes the monitor screen to change to the sprite
engine screen.  By keeping the sprite engine completely separate from VGA we
can keep costs down and standardise the market (instead of simply building
a co-processor for VGA)  So a person with EGA does not have to buy a VGA card
to use the sprite engine, he can just buy a sprite engine.  It will also not
have to worry about "windows" or "OS/2" graphics at all since it is a 
completely separate piece of equipment

POTENTIAL PROBLEMS:  Is it possible to turn off VGA through softare?


THE SPRITE ENGINE ALGORITHM:

The sprite engine will do this constantly:

When the sprite engine is turned on through software, the card will:

1)  Set the internal registers X and Y to 0 (the equivalent of setting the
    horizontal and vertical timing so the electron beam is at the top lefthand
    corner of the screen)

2)  X and Y will be checked against every element in a "Sprite Queue." if X and
    Y fall within fields 1 through 4 of the table mentioned below, it will 
    fetch a byte from a sprite definition table in DOS memory and display that 
    byte IF AND ONLY IF that fetched byte is greater than zero. (zero color
    bytes in the sprite definition are transparent) Then goto step 4.

3)  If X and Y not found, or if the fetched byte is equal to zero, calculate a 
    byte from the background tile definition table and display that instead.

4)  Update the joystick registers

5)  Increment X by one and goto step 2.  If X = 320 change X to zero and 
    increment Y, then goto step 2.  
    If Y = 201 change it back to zero, change X to zero, and goto step 2.

This loop will repeat indefinitely, 70 times a second until the sprite engine
is turned off. (keep in mind that I'm using 320x256x256 color mode, for
simplicity and speed)


        THE SPRITE QUEUE: (Defined in DOS memory)
        
            word     word word word word   double word
             |         |   |    |    |        |
             V         V   V    V    V        V
          ___________________________________________ 
         | Sprite # | X1 | Y1 | X2 | Y2 | Sprite Loc |
         |--------------------------------------------
         |          |    |    |    |    |            |
         |          |    |    |    |    |            |
         |          |    |    |    |    |            |
         |          |    |    |    |    |            |
         |          |    |    |    |    |            |
         |          |    |    |    |    |            |
         |          |    |    |    |    |            |
         |          |    |    |    |    |            |
          -------------------------------------------

If two sprites overlap, the sprite who is farther down in the queue will have
his bytes overlaid the top of the other sprite.

Sprite Loc is the segment:offset location of the beginning of the sprite 
definition.

SPRITE DEFINITION TABLE:
     ________
    |        |
    |   1    |      This table is just a straight one dimenstional array
    |________|    of bytes.  There is nothing separating the fields between  
    |   2    |    sprite defintions.  Keep in mind that the sprites can 
    |________|    have an infinite number of sizes (for example, sprite 3 is
    |        |    much bigger than sprite 2)  The beginnings of the sprite
    |        |    definitions for each sprite is stored in Sprite Loc of the
    |   3    |    sprite queue.
    |        |
    |________|
    |   n    |
    |        |
     --------


BACKGROUND TILE DEFINITION TABLE:

 ____________________________________________________________________________
|  ddd                                                                       |
| ddddd                                                       aaaaa          |
|  ddd        aaaeeeaaa                           aaaaaa                     |
|                                                                            |
|                                       ccc              aea                 |
|                                       ccc                                  |
|aaaaaa    aaaa     aa    aaaaaa     aaaaaaaaa         aaaaaaaa     aaaaaaaaa|
|aaaaaa    aaaa     aa    aaaaaa     aaaaaaaaa         aaaaaaaa     aaaaaaaaa|
 ---------------------------------------------------------------------------- 

This table is a straight array of words, organized in a matrix table so that
you can see that it kinda looks like a level from Super Mario Brothers!
The a's represent a word that contains the tile definition number, as do the
c's, d's and e's.  The blank spaces are represented by word 0 for a black
screen.  In this example, the a's represent the blocks mario walks on, the
c's represent the pipes, the d's make up the clouds, and the e's represent the
coin boxes.

TILE DEFINITION TABLE:

             Element Number    
                |
                V 
     ________   
    |        |  0
    |   1    |  
    |________|  155
    |        |  156
    |   2    |
    |________|  311  
    |        |  312
    |   3    |
    |________|  467
    |        |  468
    |   4    |
    |        |
     --------   623

Each tile definition 16x16 bytes long.
This table is just a straight array of bytes, starting at location 0.
The sprite engine calculates a byte from the tile by using the word from the
background definition table, multiplying it by 16, adding in the address of
the location of the tile definition table in DOS memory, and doing a couple
of other calculations to determine what byte to display from the tile 
definition table.


Therefore, all the IBM needs to do in order to animate objects is this:

Steps 1-4 only need to be done ONCE:
1)  Load the sprite definition table
2)  Load the Background definition table
3)  Load the Tile Definition table
4)  Load the sprite queue.

5)  Change the memory values in the sprite definition tables to move the
    object.  (change X1, Y1, X2, Y2)
6)  Change the value of X and Y to change the scrolling.


SPRITE ENGINE RAM MEMORY LOCATIONS:
The sprite engine will have a small ram chip on it to store where different
sprite table definitions are located.  Here are the memory locations:

$0 - $7: Sprite_queue_location (double word)
This memory is just 8 bytes the tell the engine where to look in general DOS
memory for the location of the sprite queue

$8 - $A: Background_table_location (double word)
This memory contains 8 bytes that tell the engine where the background table
is located 

$B - $12: Tile_def_location (double word)
This memory contains 8 bytes that tell where the table that defines the 
array where the background tiles are defined.

$13 - $14: Joystick_mem (2 bytes)
When the joystick is read, these 2 bytes will contain the following information:

Memory location: $13
           Bits:  7 6 5 4  3  2  1  0    
      Joystick1:  U D L R B1 B2 B3 B4

Memory location: $14
           Bits:  7 6 5 4  3  2  1  0    
      Joystick2:  U D L R B1 B2 B3 B4
      
U = up, D = down. L = left, R = right, B1 - B4 = buttons 1 through 4

The end of the joystick ports will look like this:
  __________________
  \  .  .  .  .  . /
   \  .  .  .  .  /   <-- Male port (pins sticking out)
    \____________/         

Skematics of Atari Joystick: (P = Power)

  P   __________________
     |
  U  |_ \_______________
     | 
  D  |- \_______________
     |
  L  |- \_______________
     |
  R  |- \_______________
     |
 B1  |_ \_______________


Well that's it!  What do you think?  Are my ideas feasible?  Any additions,
comments? suggestions?  Thanks alot for reading and talk to you soon!

THINGS THAT THIS DOCUMENT DOES NOT COVER AND NEEDS TO BE FIGURED OUT:

1) Collision detection
2) Multiple backgrounds

- Rich
  kennehra@logic.camp.clarkson.edu