Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

[Development] 94 Sprites At Once

Olle Haerstedt

Posts 110
28 Mar 2020 14:14


Already discussed in IRC channels, but this video is pretty impressive: EXTERNAL LINK 
  The routine uses 94 sprites, with sprite reuse (I assume). If you play it at 0.25 speed, you can see some light flickering. One IRC member suggested this can be done by sorting the sprites on the y-axis on each frame to decide the sprite channels.
 
  What I'm wondering is if this could be done if the sprites were all different? Or would that require to copy the memory of the sprite and sort them in this way, not only sort the pointers?
 
  The second routine is scrolling text in a circle, I assume also done with sprites. Anyone has any theories of how?
 
  Another talking point is how much CPU time is left (for possible game logic), and if it can be combined with the blitter.
 
  Thanks for reading!


Samuel Crow

Posts 424
28 Mar 2020 18:52


Olle Haerstedt wrote:

Already discussed in IRC channels, but this video is pretty impressive: EXTERNAL LINK   
  The routine uses 94 sprites, with sprite reuse (I assume). If you play it at 0.25 speed, you can see some light flickering. One IRC member suggested this can be done by sorting the sprites on the y-axis on each frame to decide the sprite channels.
 
  What I'm wondering is if this could be done if the sprites were all different? Or would that require to copy the memory of the sprite and sort them in this way, not only sort the pointers?

The palette would have to be the same 4 colors on an OCS/ECS but not on AGA or SAGA.  Also, you have to copy or blit to the sprite channel what the images are because there is only a pointer to the complete channel of data, not each individual image in the channel.
Olle wrote:

The second routine is scrolling text in a circle, I assume also done with sprites. Anyone has any theories of how?
 
Another talking point is how much CPU time is left (for possible game logic), and if it can be combined with the blitter.
 
  Thanks for reading!

Vertical muxing only for the text circle.  I saw a Commodore 64 do a similar effect in the Reticulate demo.

If you keep all the sprite images in chip RAM, you can blit the images to the channel buffers asynchrinously but the position data needs to be written by the CPU.  On the AGA and SAGA cores, longword writes are supported to speed up the bus accesses.  On SAGA there is another bit feature in the position header that allows each channel to hold a 16 color image, 32 pixels across each.


Olle Haerstedt

Posts 110
28 Mar 2020 23:21


Thanks!


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
30 Mar 2020 14:12


Sprite -reuse can be done in 2 ways
a) you have an array of sprite data in memory.
The data is structured like
X,Y - Position, PIXELDATA
X,Y - Position, PIXELDATA
X,Y - Position, PIXELDATA
X,Y - Position, PIXELDATA
X,Y - Position, PIXELDATA

b) the other way of reusing sprites is setting the PTR new with the a Copperlist. This needs a clever copperlist, but does not need then to copy the sprite data in such list




Olle Haerstedt

Posts 110
31 Mar 2020 13:21


Gunnar von Boehn wrote:

Sprite -reuse can be done in 2 ways
  a) you have an array of sprite data in memory.
  The data is structured like
  X,Y - Position, PIXELDATA
  X,Y - Position, PIXELDATA
  X,Y - Position, PIXELDATA
  X,Y - Position, PIXELDATA
  X,Y - Position, PIXELDATA
 
  b) the other way of reusing sprites is setting the PTR new with the a Copperlist. This needs a clever copperlist, but does not need then to copy the sprite data in such list
 
 

Got any link for that second option?

posts 5