From my experience the hardware sprites are the weakest part of the system, they're overly complicated to program and next to useless for actual game sprites. To me it almost feels like they were implemented as an after thought, the placement of their hardware registers support this.

They were likely implemented simply for the mouse pointer in Workbench and with not a lot of effort they were able to implement 8 of them and combine 4.

It's not that I don't appreciate them though, I do... I just wish there would have been more of them with full 16 colour support, x/y flip, chaining etc...

Having 64 of them would have been a game changer, 32 if combined even if it ate into the bitplane DMA... from a gaming perspective it would have been worth it.

The memory size limitation on the chipset I disagree with, for a system of it's time it was superb.

Hardware sprites are great on the Amiga, quite flexible, especially as you can push data to the registers with the copper.

You can use them for many different things too (not just as "game object" sprites), but for panels, for masking out things, overlays, background parallax layers, star fields, foreground effects)

Also in dual playfield, with "strange" PF vs Sprite priorities, can create some crazy effects too

They had to better work around memory layout, I still think that some parts of Amigas' OCS were not totally fixed. Why 2 cicles access for cpu, since 020 were there? Why hw register were under bitplane's schedule? Why did the trapdoor ram do the same? Why not a little dedicated memory for 68k since Amiga was a computer not a pure consolle? I don't think it was about money, it was about time...

I'm with Dan. Sprites may seem not much on Amiga but they inspire to be creative with them..
For instance, in 'Tinyus' I only used them for starfields but at the very end of the game I was not able to blit a big boss. It was just too slow with 32 colors @ 50fps (with lots of other stuff on screen).
Sprites came to the rescue and the boss worked again at 50fps https://youtu.be/LakPMXrHLs8?t=927

Actually "game object" is like the worst thing you can do with them..: :D
But they are a surprisingly helpful tool.

Bit like a swiss knife.

On the Amiga, there's always the exception to rule.. Hybris uses Sprites for nearly all objects in game (the exception being the player ship) :D

Anyway, I tend to see Sprites as great for small objects like bullets or power ups, special effects, adding some colour to Dual Playfield screens, a background layer, etc. But... I agree, I don't really see them as a good alternative to the Blitter for 'general game objects'. They're much better suited for special purposes instead.

This 100%... it's about finding creative ways to use them in conjunction with all the other hardware "features"

I'd agree they are certainly flexible(ish) and one can do very creative things with them, but they're not the strongest part of the system.

If you had an Atari ST and you could borrow two things from the Amiga hardware to improve the ST then the sprite hardware wouldn't be on my list for making better games.

It's just little things they could have included that would have made them much easier to work with such as adding modulo registers, in Rygar I had to hold two copies of some enemies in both display and sprite format. And then there's the weird way the collision detection and sprite ordering is implemented.

One thing that bothered me from the moment I found out (coming from the c64), and it still does: max. width is 16.
They should've made them 16/32 pix wide and reuse the bitplane model: 5+ bpls lores or 3+ bpls hires and bitplane dma starts stealing dma slots. So you could enable double width per sprite (or sprite pair) and it would then act as 4 bpls hires (all even and all odd slots used by sprite dma, cpu/blitter/.. get nothing, bitplane dma still has priority). Of course, buffering of additional data would be needed as well as some extra logic, but I don't think it would be much more complicated (not a hardware guy myself).

Unfortunately there would not have been enough DMA cycles to do the same model as the bitplanes: for the fetch of 16 bits (of a single sprite) a block of 4 cycles is 'reserved' (2 used), 8 cycles for the bitplanes..
Using all available cycles (as bitplanes can do), however, you could easily have 8 15-colors sprites (or 16 3-colors sprites).

Or with the same model of the bitplanes only 4 sprites at 5+ bitplanes, but I don't know how much sense it would have made.

Different for a buffered model, where the DMA would have taken care of filling the (necessary in that case) (V)RAM of the sprites, perhaps during the vblank.
But by then it would have been a different machine :)

The VICII in the C64, when all the sprites are active, it totally excludes the CPU from the BUS, lowering the cycles per line from 63 to 46-49 (the purists of the C64 don't take it badly, I simplified :), the allocation of the BUS is different, on 'bad' lines only few CPU cycles are available).
There is not the 'stealing' problem, because the C64 cannot freely use overscan (no bitmap on borders, only sprites or 'residuals').


EDIT: one thing useful would have been to be able to define when to start the fetch for the DMA of the sprites, even from 'negative' DMA slot positions, or interwined with the other channels (for example those of the refresh or audio); in this way it would have been increased, even doubled, the amount of sprites available (because anyway the fetch on 'blank' video positions). But it would have complicated Agnus' life considerably :D

I always wondered why they didn't do this. It would have made Sprites much more useful while not costing all that much in terms of lost Copper/Blitter/CPU cycles. Perhaps it's because it would require a SPRxDATC & SPRxDATD register per Sprite, or perhaps because they really didn't like to see the Copper/CPU slowed down. This would fit the design of other DMA channels during HBLANK - Refresh/Audio/Disk also only use half of the available cycles, leaving the rest for the CPU, Copper or Blitter.
If it's extra cycles stolen from the CPU you want, just run the Blitter, I hear it's quite good at doing that :D

Anyway, the C64 Sprite design is very different from a HW perspective. Still interesting as a comparison because it's an older 8 bit system which allows more Sprite pixels per scanline (even without X doubling) than the Amiga and Sprite multiplexers were routinely used on it to get around the 21 pixel height limit.

True, it basically use the same number of cycles Amiga use (but the total number of slot per line is much less!), but does it better.
The 16(*2) cycles it use are packed (8 byte pointer + 24 byte data) and use all available slots not used by refresh or video data.
A large chunk of transistors in the VICII are for their management: it is essentially a chip designed for the movement of objects.

In Agnus sprites can only use a handful of the total slots, competing with many others, and they don't even have priority ;)
However it is possible to do horizontal multiplexing which on C64 is not :great

In terms of dma bandwidth it's the same thing, 16 colors (4 bpls x 1 word) or double width (2 bpls x 2 words). Maybe saying 'the same model' isn't the best wording, because it could imply the same fetch order and interleaving as for bitplanes. What I meant is take the unreserved cycles, and there is just enough of them, to fetch extra sprite data (just like bitplane dma would for 5+/3+ lo/hi-res) and buffer them until needed later in the rasterline.

well.. with all this talk about "what they could have done"... I still stand by my assertion that the Amiga sprites are actually pretty good ;) as long as you are creative in how you use them :)

maybe we need some examples of fairly good usage..

ok.. here (in Chuck Rock 2 that I coded)...

6 sprites used for score... then reused for Chuck Jnr (4 attached sprite) and his club (2 sprites).. then also reused for the lives and health (milk) counter at bottom.. 2 sprites are free over the whole screen, so those were used for rain, and snow (in video at clickable time.. rain is at around 6:15). I wish I'd used those 2 spare sprites more in other levels for various effects


https://youtu.be/Pm_7WULpvto?t=2129

Anyone care to also post fairly decent use of sprites ?

Two examples immediately come to mind but there are many!

Mega Typhoon: massive multiplexing.
Apidya Techno level: the great animated full screen background completely made of sprites.

Risky Woods was always a favourite of mine, good use of sprites for the background.

Amiga sprites should be much more versatile than they are. But once you try to live with shortcomings like sprite-DMAs inability to redirect itself to memory locations, I think they can be put to good use. "Reshoot R" uses vertical multiplexed sprites to draw scoreboard, player ship, all bullets. A third parallax scrolling layer entirely built from one single animated horizontally multiplexed sprite, to enhance the visual depth. Quite massive use of sprites, actually.

Nice side effect: In the few moments when draw rate drops from 50 fps to 25 fps due to massive blitter-dma, all sprites-based objects still keep moving at 50 fps as they are controlled by custom code. Same is true for hardware scrolling. This way, even a well-trained will have a hard time to notice the framerate flux.

Top and bottom logos are sprites. Top logo is much wider then 128 pixel, it was especially designed this way to work with sprites.. I would have never layouted the logo without the given sprites limitations.. so sprites inspire for different art :)


https://www.lemonamiga.com/games/med..._driver_01.png


Score, gas display, coins display on bottom are sprites

https://www.lemonamiga.com/games/med..._driver_02.png

Sprites and blitter are not mutually exclusive. If you point the blitter at a 16-pixel-wide interleaved "screen" you can use it like a narrow playfield. Also, opaque blits are twice as fast as "cookie-cutter" blits due to the mask and background image not having to be read in by the blitter.

On AGA, this usage gets even better! 64-pixel-wide sidebar screens are quite useful as are floating toolbars. Add to that the fact that the palette selection can be directed to any one of the 16 banks of 16 colors each and you can double-buffer the palette entries used by a custom copper-list.