• Home
• Archive
• About
• Links
• Store
•  
• Cross-dev Tools
  • Cyrene
  • Cadius
  • KEGS
  • LZ4 Data Compression
  • Merlin 32
  • Mr Sprite
  • Mr Sprite Tech
  • OMF Analyzer
  • Window Capture
• Products
• Projects
• Source Code
• Unreleased
•  
• Apple Cassettes Tapes
• Documentation
• Apple IIgs Diskazines
• French Software
• French Underground
• Tribute to...
•  
• Apple II documentation project

Mr Sprite Tech

(C) 2012-2013 by Antoine VIGNAU and Olivier ZARDINI

---

CPU


GRAPHICS


Conclusion

A sprite is a visual object you want to display on a screen. It can be of any size and usually we define it by its width & height. We can draw a frame around it to define its limit (in sprite sheet) or isolate each sprite in its own picture :

Even if a Sprite is defined by the frame containing all its pixels, the sprite itself is not a rectangle. Some pixels in the frame define the Sprites, the other ones are considered as 'background' (in light blue here).
The sprite is supposed to be displayed on a picture. The picture with no sprite is named 'background', as opposite to the sprites supposed to be displayed in the foreground.

If we directly cut / paste the sprite in the picture, we bring also the sprite background color (light blue), and we probably don't want that !

Each black color pixel defines a valid sprite pixel and the white one define a background pixel. We can now use the Mask to properly insert the sprite into the background picture :


When you create Apple IIgs games, you provide the Sprite sheet and the Mask sheet together. To simplify Sprite & Mask identification, you organize them in the same order in both of your pictures. Here is a Sprite + Mask sheets example comming from LemminGS game :





The mask MUST use 2 values : 0 (black) for the Sprite pixels and F (white) for the background :


The background can use any 0-F values, we don't really care about :


If the pixel values for Sprite background and Mask are imperative, it is because the way the Masking process works :

Let's see that :
      - First step, let's apply the Mask on the Background picture using a AND operation :  Intermediate = Background AND Mask

  The logical AND forces to 0 all pixels of the Background picture matching a 0 value from Mask (don't change values for pixels matching a F value). The AND operation 'clears' the background picture in the area where the sprite will be displayed.

      - Second step, we apply the Sprite on the Intermediate picture using a OR operation : Result = Intermediate OR Sprite

 The logical OR changes all pixels of the Intermediate picture matching a non 0 value from Mask (don't change pixels matching a 0 value). The OR operation draws the sprite into the intermediate picture.

  To summarize, we obtain the Result Picture with a combinaison of 2 logical operations : Result = (Background AND Mask) OR Sprite

   Here we don't care about the colors (blue, green, white, black...). The only mandatory thing is to have 0 and F values for Mask and 0 for Sprite background. The AND / OR operations work only with these values.

The classic way to display a sprite on an Apple IIgs screen use the following Code sequence, for all the pixels of the sprites :




To draw 1 line of the Sprite, we have to loop over all pixels of the line, using sprite width as limit. We start the code by initializing the screen address where to display the sprite and the Sprite + Mask address :


We have now to loop over all lines (sprite height) to draw the whole sprite :


The green Code lines are only executed once.  The blue ones are executed once per Row (sprite height). The Red ones are executed for each 16 bits (4 pixels) values (sprite heigth * sprite width / 4).

If we choose to not count the green ones, the number of cycles required to display a sprite on the Apple IIgs screen is :


The formula is :  #cycles = 5 + SpriteHeigth*(3+(SpriteWidth/4 * 31) - 1 + 41) - 1


For our Sprite (width=36, height=62), the result is 19968 cycles. A little bit more because we need to initialize the address for Sprite, Mask and screen. We have also to add the RTS at the end of the code.

Let's test a few Sprites to see how many cycles they need to be displayed. Remember, we have around 41,500 cycles available per scan if we want 60 pictures / second animation.

We have selected a set of Sprites from different famous Arcade games, displayed here in a 320x200 screen where you can see their relative sizes :


Each sprite has between 3 and 16 colors. There is a mix of different sizes. On a modern high resolution screen, the native 320x200 looks too small so we have magnified x2 all pictures for a better view. We provide the original Sprite but also the complexity analysis graphic provided by Mr Sprite.

Karate Champ 32x48 pixels 2168 cycles	Double Dragon 20x63 pixels 2479 cycles	Double Dragon 20x61 pixels 2472 cycles	Double Dragon 32x75 pixels 3591 cycles	Shinobi 32x57 pixels 2593 cycles	Shinobi 32x64 pixels 3134 cycles	Golden Axe 56x65 pixels 3693 cycles	Golden Axe 44x73 pixels 3168 cycles

Street Fighter 1 56x92 pixels 6045 cycles	Final Fight 84x93 pixels 7193 cycles	Final Fight 56x93 pixels 6463 cycles	Street Fighter II 116x94 pixels 7056 cycles	Metal Slug 164x75 pixels 10198 cycles	Metal Slug 156x121 pixels 15967 cycles

Here is an animation of the Metal Slug UFO Sprite using 24 different pictures (widht=156, height=121) provided as a .2mg image disk (source code available on disk). The animation runs at 60 frames / second.

Click to run the animation, click again to quit. The red border shows the CPU usage (the sprite display is of course faster at 8 Mhz than at 2,5 !) . We start to draw the Sprite when the spot is refreshing the line located under the Sprite :


We will go back into details in this aspect (real cycles / theoretical cycles) in a next article when we will look at sprites animation, where the synchronisation with the spot requires all our attention.