Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

SAGA Spritespage  1 2 3 4 5 

Vladimir Repcak

Posts 354
08 Aug 2020 01:44


So, are these sprites useable for something like 2D HUD ?

Meaning, I don't have to manually copy every pixel (and check for transparency) anymore on CPU into RTG (CGX) framebuffer ?


Gunnar von Boehn
(Apollo Team Member)
Posts 4906
08 Aug 2020 08:27


Vladimir Repcak wrote:

So, are these sprites useable for something like 2D HUD ?
 
  Meaning, I don't have to manually copy every pixel (and check for transparency) anymore on CPU into RTG (CGX) framebuffer ?

Sprites are small GFX elements which are displayed by the hardware and can be moved by the GFX hardware. The typical sprite everybody uses is the mouse-pointer.

The Amiga GFX display consists of "playfields" and sprites.
Playfields are layers which are normally used for background.
The Amiga display support 2 of these layers and 8 Sprite channel.
Each Sprite channel can show 1 Sprite per row. One channel can show many sprites as long they are all below each other.

Showing several sprites with one channel of commonly done for "bullets" in games.
A single sprite can have variable size .. from 1 pixel to 256 pixel height or more.
Each sprites can have a width of either 16, 32 or 64 pixel.
With putting sprites together you can even create a 3rd background playfield.

A background layers fully done with sprites is also done sometimes in Amiga games.

The RTG display buffer on the Vampire supports 1 extra Sprite.

Today the V4SA provides the SAGA chipset.
SAGA is the combination of AGA + Enhancements.
This combination today supports 2 playfields, SAGA Sprites channels, 1 Chunky(RTG) playfields and 1 PIP (Picture in picture) playfield.




Samuel Crow

Posts 395
08 Aug 2020 15:31


Vladimir Repcak wrote:

So, are these sprites useable for something like 2D HUD ?
 
  Meaning, I don't have to manually copy every pixel (and check for transparency) anymore on CPU into RTG (CGX) framebuffer ?

The transparency for color 0 is always there for sprites.

As for making a HUD, AGA sprites were already useful for that.  I did a simple OS hack that copied the pointers from a SimpleSprite structure to a BitMap structure and used that to make a RastPort for the sprite DMA.  This allowed the use of the blitter when copying to the sprite, not to mention text plotting.

Using a 64-pixel-wide sprite with the bordersprite bit set allows the HUD to overlap the extended left border when horizontally scrolling on AGA.  You just have to make sure color 0 isn't used and that the sprite is far enough right that it doesn't overlap its own DMA fetch.


Philippe Flype
(Apollo Team Member)
Posts 295
08 Aug 2020 16:17


Vladimir Repcak wrote:

  So, are these sprites useable for something like 2D HUD ?
 
  Meaning, I don't have to manually copy every pixel (and check for transparency) anymore on CPU into RTG (CGX) framebuffer ?
 

 
 
 
Question is about using Sprites onto a RTG/Chunky layer.
 
Answer is NO, for now.
 
Sprites are part of the AGA chipset.

So sprites displays onto Planar layers, not onto RTG layer.
 
On V4, at moment, even with so called 'Super' AGA you cant do that.
 
In future, V4 goal is to homogenize Planar and Chunky modes so that Sprites may work onto Chunky layer.
 
To think further, with current V4 SAGA, eventually some HUD layer could be implemented with the PiP layer, which can display onto the Chunky layer.
 
PiP refresh is free, the layer behind is not destroyed, so no blit needed.
 
Also it have a ColorKey for the transparency.
 
PiP is still not fully finished, though.
 
For example, depending of the coder need a register controlling the Priority order (which layer goes onto which one).


Gunnar von Boehn
(Apollo Team Member)
Posts 4906
08 Aug 2020 17:56


Philippe Flype wrote:

  Answer is NO, for now.
   
  Sprites are part of the AGA chipset.
 
  So sprites displays onto Planar layers, not onto RTG layer.
 

 
The answer is more complex.
Yes as mentioned there are several layers.
Sprite, Planes, Chunky, PIP.
 
The AGA layer with Sprites can be shown on Chunky.
Also PIP can be shown on Chunky.
And PIP can be shown on AGA-PLANAR.
And it fact all 3 could be shown - if you enable all of them.
 
But mind we talk about V4 feature here only.
And the core which is right allows all this, is today internal.
We might released a beta this week.
 


Vladimir Repcak

Posts 354
09 Aug 2020 06:26


Thanks for answers.

I wouldn't mind if it took few months to get enabled in the newest core, as I am still some months away from finishing.

But V4-only? I certainly don't want to create V4-only game. Of course, ideally there would be separate V4 codepath. Other than the coding effort, it's not impossible..

Is there some technical reason why the same Sprite functionality could not be simply copied into V2?

Do you guys perhaps have to reimplement V4 features from scratch into V2 core?


Gunnar von Boehn
(Apollo Team Member)
Posts 4906
09 Aug 2020 07:26


Vladimir Repcak wrote:

Is there some technical reason why the same Sprite functionality could not be simply copied into V2?
 
Do you guys perhaps have to reimplement V4 features from scratch into V2 core?

The Vampire 2 are accelerators.
The Amiga chipset runs fully original with all Vampire 2 cards.
The Vampire 2 only works as CPU accelerator plus GFX card.
So putting an Vampire 2 into your Amiga is exactly the same as putting a CPU accelerator in your A2000 plus a GFX card into your A2000. The Amiga stays the same and works the same.

The Vampire 4-SA on the other hand is a complete new Amiga.
The Vampire 4 comes with Super-AGA chipset this means this is AGA chipset plus all the enhancements which we believe that the original engineers like Dave Hayne would have wanted to build in the next Amiga chipset. And all these features, new and old are put together in an harmonized way. This allows using all of them in parallel.

So right now the combination of these features is only available in the V4.




Antony Coello

Posts 48
13 Aug 2020 12:39


Gunnar von Boehn wrote:

 
  The Vampire 2 are accelerators.
  The Amiga chipset runs fully original with all Vampire 2 cards.
  The Vampire 2 only works as CPU accelerator plus GFX card.
  So putting an Vampire 2 into your Amiga is exactly the same as putting a CPU accelerator in your A2000 plus a GFX card into your A2000. The Amiga stays the same and works the same.
 
 
  The Vampire 4-SA on the other hand is a complete new Amiga.
  The Vampire 4 comes with Super-AGA chipset this means this is AGA chipset plus all the enhancements which we believe that the original engineers like Dave Hayne would have wanted to build in the next Amiga chipset. And all these features, new and old are put together in an harmonized way. This allows using all of them in parallel.
 
  So right now the combination of these features is only available in the V4.
 
 

Ok, I think at some point there needs to be clear documentation, if not an accurate set of hardware reference/implementation manuals.

At a minimum, your own products page:
EXTERNAL LINK

states that the V500/600 cards DO have SAGA GFX.

It was my understanding that they had OCS/ECS + RTG. Which is it?

Also, is there a difference between the advertised 'Super AGA' of the V4 and 'SAGA' on the 1200/600/500?

I completely understand that the goalposts may still be moving as to what is available for each model, but the above quoted post has not made things clear. Especially for coders looking for implementation specifics.
 


Kamelito Loveless

Posts 119
02 Sep 2020 16:56


After reading that the ZX Spectrum Next do have 128 sprites, Iím not impressed anymore by the SAGA sprites.


Vojin Vidanovic

Posts 1719
02 Sep 2020 19:02


Kamelito Loveless wrote:

After reading that the ZX Spectrum Next do have 128 sprites, Iím not impressed anymore by the SAGA sprites.

While I like how Next expands ZX128 design, Spectrum sprites are way other league, low res, no collision detection, no blitter fields etc.

Good luck with  Wonderful Dizzy and Donkey Kong.


Kamelito Loveless

Posts 119
05 Sep 2020 09:32


Vojin Vidanovic wrote:

 
Kamelito Loveless wrote:

  After reading that the ZX Spectrum Next do have 128 sprites, Iím not impressed anymore by the SAGA sprites.
 

 
  While I like how Next expands ZX128 design, Spectrum sprites are way other league, low res, no collision detection, no blitter fields etc.
 
  Good luck with  Wonderful Dizzy and Donkey Kong.
 

 
  There is more new games on the Next than one the Vampire as for sprites I think the Amiga/Vampire are way behind.
 
  Total of 128 sprites
  Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
  Minimum of 100 sprites per scanline*
  Choice of 512 colours for each pixel
  Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
  Sprites can be mirrored and rotated
  Sprites can be grouped together to form larger sprites under the control of a single anchor
  A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
  A per sprite palette offset allows sprites to share images but colour them differently
  A nextreg interface allows the copper to move sprites during the video frame
 
  No blitter but they have a copper.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 4906
05 Sep 2020 13:55


Kamelito Loveless wrote:

After reading that the ZX Spectrum Next do have 128 sprites, Iím not impressed anymore by the SAGA sprites.

 
This comparison is apples with cheeries.
 
And if you not 100% understand the topic the different numbers can easily mislead you.
So if you not have experience in Sprite coding : How can you compare these numbers?
 
I think Sprites on Amiga have both some advantages and disadvantages.
 
One advantage is clearly available memory.
On SAGA you have 512 MB available sprite memory.
How much is it on the Spectrum? 16KB?
 
If you look at maximum number of sprites on Amiga
then you can to take into accounts that sprites can be re-used on Amiga.
This means in extrem cases you can show up to over 2000 sprites on screen on Amiga this way.

Zooming and mirroring degrades visual quality but is good for systems with very little memory.
So if you have a system with "plenty" of memory then using these effects will be make the game look worse. The much better solution is having the sprites in higher quality in memory.
E.g when plain mirror a sprite looks often bad.
In reality you want to draw the sprite 2 times and each time with right light/shadow effects.

So on a System with plenty memory like SAGA with 512MB .. the best solution is having the sprite 2 times with proper shadow in memory..
But on a system with minimal memory this can not be done...
This means Mirror is "hack" to help yourself here.
So this is not a real feature...



Kamelito Loveless

Posts 119
06 Sep 2020 10:37


I know how sprites works on the Amiga, that multiplexing can be done to have more of them  onscreen, I think it can also be done on the Next, not sure about the memory space available for sprites on the Next but they should have expanded the CPU like it has been done with the 65c816 at least. Yo


Gunnar von Boehn
(Apollo Team Member)
Posts 4906
06 Sep 2020 11:12


Kamelito Loveless wrote:

  not sure about the memory space available for sprites
 

 
Lets look at the memory. I think for making games having enough Sprite memory is very important.

Lets say you want to make a simple Streetfighter game
With a player being 64x64 pixel big.
With 16 color this game sprite needs 2KB space per frame.
So if you have a game with 3 players on screen like IK+ then  you need 6 KB sprite space for it.
Lets say your Sprite can do 15 different moves and each move has 5 frames for the animation.
This means your game uses 75 animation frames per player.
This is 150 KB of sprites per player.

If you have 3 different animated Sprites on the Screen then you use 450 KB sprite space for animations.
 
Its very easy to see here that even with "only" 3 Sprites.
You can not easily solve this if you have only 16KB memory.
 
If I understand the Spectrum concept right - then they can not do such game - while the A1200 could have done it easily.
 


Kamelito Loveless

Posts 119
06 Sep 2020 18:35


I asked and the memory is indeed 16k.
« 16KB, so 64 x 256 colour sprites or 128 x 4bit 16 colour. « 


Gunnar von Boehn
(Apollo Team Member)
Posts 4906
06 Sep 2020 18:59


Kamelito Loveless wrote:

I asked and the memory is indeed 16k.
  « 16KB, so 64 x 256 colour sprites or 128 x 4bit 16 colour. « 

How would you do the animation?
16KB is not enough for 1 animated Streetfighter sprite...



Kamelito Loveless

Posts 119
06 Sep 2020 21:45


If I got it right they store other sprites (sheets) in another part of the memory and transfer them to the sprites memory using DMA + other tricks like mirroring and changing palette...
12 frames for sub zero so 144 sprites.
EXTERNAL LINK 


Gunnar von Boehn
(Apollo Team Member)
Posts 4906
06 Sep 2020 23:48


Kamelito Loveless wrote:

If I got it right they store other sprites (sheets) in another part of the memory and transfer them to the sprites memory using DMA + other tricks like mirroring and changing palette...

See its exactly like I said...
Comparing numbers is very complex..

As when you have only 16KB for Sprites ...
and use DMA to copy/swap frames in and out..
Then the DMA needs space in the 16Kb too. and needs also time to copy the data in/out ...

So there are a lot other limitations the coding is as not easy as Sprite coding should be ... as you see now that first need to blit in the sprite data to then be able to use the sprite...

One can now start to compare this to BOBs and see if using the Blitter in the first place would been another option.

But in anyway its as expected : the numbers are misleading :)


Vladimir Repcak

Posts 354
07 Sep 2020 03:24


I don't understand how can we even begin to compare Spectrum Next.

Yes, it's a beautiful machine. For what it is.

And it is:
- 8 bit Z80 @ 28 MHz
- 768 KB RAM is accessed via bank switching (within 64 KB!)

Realistically, depending on which ULA mode you work with, you only have 16 KB slot available for switching !

And don't get me started on how larger framebuffer must basically be copied over the course of several frames using DMA because you can't simply switch pointer to a different framebuffer. You must break your rendering into screen segments, each fitting into 16 KB.

Yes, you have also a bank switching mode where you have an 8 KB granularity, but that brings another set of issues that butcher your design right from the start.

Doing anything slightly more involved than Frogger on Spectrum Next is an exercise in self-abuse. You really, really must love Spectrum !


Kamelito Loveless

Posts 119
07 Sep 2020 06:55


Gunnar von Boehn wrote:

Kamelito Loveless wrote:

  If I got it right they store other sprites (sheets) in another part of the memory and transfer them to the sprites memory using DMA + other tricks like mirroring and changing palette...
 

 
  See its exactly like I said...
  Comparing numbers is very complex..
 
  As when you have only 16KB for Sprites ...
  and use DMA to copy/swap frames in and out..
  Then the DMA needs space in the 16Kb too. and needs also time to copy the data in/out ...
 
  So there are a lot other limitations the coding is as not easy as Sprite coding should be ... as you see now that first need to blit in the sprite data to then be able to use the sprite...
 
  One can now start to compare this to BOBs and see if using the Blitter in the first place would been another option.
 
  But in anyway its as expected : the numbers are misleading :)

True, thanks for the chat, every time I look elsewhere in the end I come back to the Amiga. :)


posts 86page  1 2 3 4 5