Frank B wrote:
mc6809e wrote:At least the hardware sprites are still usable, though small -- just 128 pixels of sprite data per scanline.
Had sprites been 32 pixels wide instead of just 16 there might have been a few more HAM games.
64 wide I believe and not 128. How many are available with scrolling extra fetch and fmode set to max? One 3 colour (3 + transp) I think?
My memory is fuzzy on the topic.
I'm mean on OCS. There are eight sprites per scanline that are each 16 pixels wide. Each pair of sprites share a group of three palette entries. That gives a total of 128 pixels of sprite data per scanline and 12 colors.
Pairs of sprites can also be attached. Attached sprites, where they overlap, select from 15 palette entries. That typically gives four, 16 pixel-wide, 15-color sprites. That might be where you're getting the 64 pixel number from.
Partial overlap of attached sprites is possible, too, giving wider sprites with some limits on colors. For example, two attached sprites can be partially overlapped to create a 24 pixel-wide sprite with the left four pixels selecting from three colors, the center 16 pixels selecting from 15 colors, and the right four pixels selecting from a second set of three colors. Such a scheme would give 96 pixels of sprite on a line and in most cases allow 15 color sprites.
Sprites can also be repositioned with the copper or CPU during the scanline allowing them to be reused with some limitations.
I'm not sure what the absolute limit on the total number of sprites obtained per scanline. A MOVEM.L d0-d7/a0-a7, sprites should be able to rewrite the entire set of sprites each scanline. That would give a limit of 16 sprites per scanline combining DMA fetch and CPU writes. In HAM sprites are still available, although there are fewer DMA slots available for tricks. The practical limit in any case is probably 10-12 sprites per scanline.
It's a mystery to me why someone didn't bother to try writing some simple galaga-style game using sprites on a HAM background. HAM is also fully vertically scrollable, BTW (also horizontally scrollable but care must be taken to hide artifacts). Vertical scrolling over static terrain with sprites overlaid probably had some potential. Perhaps memory limits were an issue (one HAM screen is 40K).
This discussion is actually connected somewhat to the mention of the extra address bus. Anyone that's done Atari 2600 programming knows that playfield and sprite data must be written manually by the processor every scanline. The separate address bus on the Amiga is what allows the chipset to do similar writes to arbitrary register locations. As the one of the designers of the 2600 also designed the Amiga chipset, this extra bus was seen as a great advantage, allowing the CPU to be bypassed and sprite data to be automatically loaded.
As far as scrolling goes, on OCS, the last sprite can be controlled by the copper or CPU if hard scrolling a 320 pixel wide screen with normal centering (a 304 pixel wide screen doesn't have that problem if you're willing to accept a narrower screen). Sprites don't become unusable with wider, overscan, and hardware scrolled screens. They simply must be programmed manually by the CPU or copper as the DMA slots normally used for some of the sprite are reallocated to bitplane DMA.
It's also possible to reuse sprites in the vertical by just using DMA and no tricks. DMA will automatically read in new position and control values for a new sprite at the end of the old sprite. This uses one scanline. Of course the copper can also do this if the programmer doesn't want one scanline to separate the new sprite from the old. This shifting position on a per scanline basis can also make sprites look much wider. A tree standing at a slant might span a total of 32 pixels, but if it's only 16 pixels wide at any one point, the copper and slant it.
I'm really not that familiar with AGA. Those sprites are wider I believe.