BLITZ 2.1 or AMOS Pro best for full AGA sprite support?

[ImmortalA1000]

Whilst I found the OCS sprites bit of a token gesture as a 1982 C64 owner that let down the chipset a bit I am very interested in using 32 or 64 pixel wide 16 colour each(?) sprites. Now as I understand it after a hell of a lot of hit and miss internet searches (over half an hour) you can have 64 pixel wide 16 colour sprites, sprite palette being one of 8 options of 16 adjacent palette colour indexes in sequence, so you select colours 1-16 or 17-32 or 33-48 etc (I don't call the first palette colour index zero, that's what the machine thinks it should be called but you know what I mean). The palette selection business actually reminds me of the NES but that only has room for 4 3 colour palettes (+ transparent making "4 colour" NES sprites).

Is this correct? Basically can I just define my 64 colour sprite image data, pick which 1/8 16 colour groupings of the entire 256 colour palette and place it anywhere on the open screen (which will be full pal overscan lo-res (384 x 288ish so sprites can be hidden off screen even when active)

Of course no fancy stuff, a bit like Ocean's Laser BASIC game with a good use of 8 max on screen C64 hardware sprites.

So I need a fully implemented AGA Sprite function not a hack of OCS routines in either of those two packages. Don't mind which as I used both a few decades ago for all sorts of coding (relational object orientated database with memory turbo cache in Blitz lol).

Also, is there a performance issue for the AGA chipset response times to either BASIC when using all 8 64 pixel wide hardware sprites on screen (no multiplexing on horizontal lines etc), possibly with a regular smooth scrolling screen-128 if not 256 colours is enough)?

Thanks, been out of the loop for decades with any updates/patches you can download to extend AGA support of both of these packages after the original was launched.

[Samurai_Crow]

Originally Posted by ImmortalA1000

Whilst I found the OCS sprites bit of a token gesture as a 1982 C64 owner that let down the chipset a bit I am very interested in using 32 or 64 pixel wide 16 colour each(?) sprites. Now as I understand it after a hell of a lot of hit and miss internet searches (over half an hour) you can have 64 pixel wide 16 colour sprites, sprite palette being one of 8 options of 16 adjacent palette colour indexes in sequence, so you select colours 1-16 or 17-32 or 33-48 etc (I don't call the first palette colour index zero, that's what the machine thinks it should be called but you know what I mean). The palette selection business actually reminds me of the NES but that only has room for 4 3 colour palettes (+ transparent making "4 colour" NES sprites).

Is this correct? Basically can I just define my 64 colour sprite image data, pick which 1/8 16 colour groupings of the entire 256 colour palette and place it anywhere on the open screen (which will be full pal overscan lo-res (384 x 288ish so sprites can be hidden off screen even when active)

Of course no fancy stuff, a bit like Ocean's Laser BASIC game with a good use of 8 max on screen C64 hardware sprites.

So I need a fully implemented AGA Sprite function not a hack of OCS routines in either of those two packages. Don't mind which as I used both a few decades ago for all sorts of coding (relational object orientated database with memory turbo cache in Blitz lol).

Also, is there a performance issue for the AGA chipset response times to either BASIC when using all 8 64 pixel wide hardware sprites on screen (no multiplexing on horizontal lines etc), possibly with a regular smooth scrolling screen-128 if not 256 colours is enough)?

Thanks, been out of the loop for decades with any updates/patches you can download to extend AGA support of both of these packages after the original was launched.

AGA is currently unsupported in AmosPro so use Blitz. Blitz compiler makes faster code too.

Note that if you use 15 color sprites it reduces you to 4 sprites. AGA can use bank select to give you 3 unique palette entries for each sprite if you choose that option.

[Daedalus]

Also, if you use 15-colour sprites, they will all share the *same* 15-colour palette. There's no performance issue as regards slowing things down (sprites are effectively "free" on the Amiga), but you are limited in the number of DMA slots available, and these must be shared between sprites and the Copper as it builds the screen. The end result is that there aren't enough DMA slots available to use all 8 64-bit sprites *and* display the full width of the screen. Since sprites have a lower priority than bitplanes, the last sprite channel will disappear when you run out of DMA slots. You an use all 8 sprites by reducing the width of the display - it's a technique used by Super Skidmarks to get all 8 players running at once, for example.

[roondar]

The number of sprites you can display is only limited by display width. The Copper actually has no impact, it's just about bitplane DMA.

Also (and perhaps confusingly), AGA imposes some further limits on displays and sprites that didn't exist under OCS/ECS. I don't know if you actually run into these limits when using Blitz Basic (as they depend on how Blitz sets up the hardware), though.

[Coagulus]

Yeah in Blitz you have to narrow the display to grey all the sprites working. Certainly if using hardware scrolling.

[ImmortalA1000]

Thanks to everybody

Question: I read that the 8 AGA sprites were all 16 colours each (15+transparent) unlike OCS/ECS ones which are like the NES (16 pixels wide and 3 colours+transparent with selectable predefined palettes or 3 colours)Is this not the case? Also read AGA sprite widths are either 16,32 or 64 pixels wide selectable and you have eight possible 16 colour palettes (256/16 screen palette index entries) and that you can also specify the pixel movement of sprites in steps ranging from lo-res/hi-res/super hi-res too.

So why would I be limited to pairing up sprites from OCS restrictions? Is this due to Blitz not having a fan/official made update for full AGA spec sprite features available?

edit: found this AA chipset update for specs and it mentions everything except each AGA sprite being 16 colours with sprite 1 being colours 1-16 and sprite 2 being palette colours 17-32 etc which I read somewhere else. Now I am confused whether AGA sprites are 8 x 16 (15+trans) colour sprites up to 64 pixels wide or 8 x 4 (3+trans) colour sprites up to 64 pixels wide.

http://shanson.com/spencer/Amiga-AA-Chipset.pdf

[ImmortalA1000]

Originally Posted by Coagulus

Yeah in Blitz you have to narrow the display to grey all the sprites working. Certainly if using hardware scrolling.

Probably wouldn't use scrolling at first, just basic defining/moving the 8 sprites around type game designs I would do on a C64 back in the 80s, a bit like some mini games inside more complex Cinemaware style games etc where if I can offload some performance hit to the blitter routines of AMOS/Blitz it would look much better on AGA due to sprites advantage even if the game is still only 32 colour backgrounds.

The use of simply manipulated hardware sprites alone if possible would minimise the speed difference between using 68k as opposed to whatever the performance of the built in blitter libs of AMOS/Blitz, capabilities a bit like the better off the shelf games oriented BASICs for the C64 like Laser Basic AKA Basic Lightning moving round fast and fuss free C64 sprites vs software sprites within Laser Basic for the Amstrad/Sinclair machine (same abilities, different performance).

[Daedalus]

Originally Posted by roondar

The Copper actually has no impact, it's just about bitplane DMA.

Sorry, you're right, I for whatever reason was thinking of the Copper initiating bitplane DMA, but that's not the case.

Originally Posted by ImmortalA1000

Question: I read that the 8 AGA sprites were all 16 colours each (15+transparent) unlike OCS/ECS ones which are like the NES (16 pixels wide and 3 colours+transparent with selectable predefined palettes or 3 colours)Is this not the case?

This is incorrect. you're limited to 3 colours, just like OCS/ECS.

Also read AGA sprite widths are either 16,32 or 64 pixels wide selectable

This is correct. You need to set the sprite fetch mode, and those widths correspond to mode 0, 1 or 2. OCS and ECS can only use mode 0.

and you have eight possible 16 colour palettes (256/16 screen palette index entries)

This is sort of true. You can pick any bank of 16 pens for even sprite channel colours, and any bank of 16 pens for odd sprite colours. There are 16 possible banks (256 / 16 = 16).

and that you can also specify the pixel movement of sprites in steps ranging from lo-res/hi-res/super hi-res too.

Yep, to do this in Blitz just use a quick type variable and set the position in fractions of a pixel.

So why would I be limited to pairing up sprites from OCS restrictions? Is this due to Blitz not having a fan/official made update for full AGA spec sprite features available?

No, you need to pair sprites to have 16 colours. This combines the 2 bitplanes from each 4-colour (3 + transparent) sprite in the pair to give 4 bitplanes, so 16 colours (one being transparent). It's a hardware thing, not a Blitz thing.

edit: found this AA chipset update for specs and it mentions everything except each AGA sprite being 16 colours with sprite 1 being colours 1-16 and sprite 2 being palette colours 17-32 etc which I read somewhere else.

By default, AGA sprites use the same bank of colours as OCS/ECS sprites for compatibility - that's pens 16-31 for all sprites, with 16 being transparent. On AGA, you can set even and odd sprite channels to use different banks of 16 colours, which means that each 3-colour sprite can use a different 3 colours, since 4 sprite channels are assigned to each bank. But if you combine sprites to create 16-colour sprites, they will only use the bank for odd sprite channels (the corresponding even channel is effectively disabled), so all combined sprites must use the same set of 16 colours.

Now I am confused whether AGA sprites are 8 x 16 (15+trans) colour sprites up to 64 pixels wide or 8 x 4 (3+trans) colour sprites up to 64 pixels wide.

They are 8 x 4-colour sprites up to 64 pixels wide.

[ImmortalA1000]

Many thanks for clearing that up. It's good and bad news I guess, bad news you still lose half the sprites per line as 4 per line is really not enough but required to avoid the still present restriction of 3 differently coloured sprite (which is too NES looking even in 16 pixels wide). But if you make a game that uses 240/224 colours you can save the last 16/32 colours as sprite unique palette banks to use, a problem the OCS 32/64 colour games had is now fixed then because 224 colours for an Amiga bob/bitmap to use is plenty even compared to my favourite 68k based arcade games.

Whilst I won't be able to write the same sort of static screen or minimal scrolling slowly type games I was hoping for (4 per line is not enough or 3 colours is not enough per sprite) it is interesting that you can get a triple playfield effect of 3x 16 or 2x 16 colours + 32 colours via sprite layer using alt palette bank colour (tricky pixel art restriction there aligning the palette vertically but hey that's an artistic not technical problem) for literally no chipset bandwidth if you keep to 256 pixel width screens. Four 64 pixel wide 16 colour sprites placed next to each other horizontally and scrolled at super hi-res or just hi-res accuracy and then the image displayed by the 4 sprites on a line redefined every 4th(super hi-res accuracy movement used other wist ever 2 frames if hi-res movement used) frame one pixel to the left or right would give a really smooth slow scroll of lowest background layer. I believe the SNES is only 256 pixels across in lo-res so it does give you an interesting jumping off point for 'free' parallax layers under 128/256 colour bitmap on an AGA Amiga.

Of course dual playfield plus sprite layer would mean I am limited to 16 colours for the bobs on each actual playfield but there is still the option of a regular bitmap screen 2-256 colours total and using the sprites as a pseudo dual playfield underlay/overlay of the 16 or 32 colours via sprites. I am of course assuming that sprite definition from memory via pointers is similar to the relatively lightning fast C64 implementation.

But it looks like to get arcade quality 'bigness' of huge colourful moving onscreen characters it would have to be Blitter control via ASM, expertly written. No wonder arcade machines opted for sprites over blitter during the life of the A1000.

For me the limit was always losing half the sprites to have more than 3 colours. Still they are more useful, potentially much more useful, just not in the way I expected

[Daedalus]

Yep, many games use sprites for an added layer of parallax. How many sprites were you looking to use? You can combine usage, for example, two 64-pixel, 16 colour sprites and four 64-pixel, 8-colour sprites is fine.

Also, bear in mind that there are a couple of tricks you can do relatively easily with the Copper to get a bit of extra leeway with the sprites. First, sprites are the full height of the screen, and you can redefine the palette at different lines on the screen, so if they don't need to overlap you can have more colours included in the sprites. Second, you can re-use sprites by resetting them at a certain Y position on the screen. This gives you all 8 sprites again and lets you re-use them at will. Provided they don't ever overlap , this can be used to easily get up to 16 sprites on screen at once, and probably more if you dig a little deeper.

Yep, the sprite definitions are handled by pointers, meaning they can easily be changed or animated by pointing at the different frames in memory when necessary.

[ImmortalA1000]

Originally Posted by Daedalus

Yep, many games use sprites for an added layer of parallax. How many sprites were you looking to use? You can combine usage, for example, two 64-pixel, 16 colour sprites and four 64-pixel, 8-colour sprites is fine.

Also, bear in mind that there are a couple of tricks you can do relatively easily with the Copper to get a bit of extra leeway with the sprites. First, sprites are the full height of the screen, and you can redefine the palette at different lines on the screen, so if they don't need to overlap you can have more colours included in the sprites. Second, you can re-use sprites by resetting them at a certain Y position on the screen. This gives you all 8 sprites again and lets you re-use them at will. Provided they don't ever overlap , this can be used to easily get up to 16 sprites on screen at once, and probably more if you dig a little deeper.

Yep, the sprite definitions are handled by pointers, meaning they can easily be changed or animated by pointing at the different frames in memory when necessary.

As the sprites align vertically between 3 and 15 colour possibilities and the 3 colours are all unique for each sprite I thought it would be tricky to draw a natural looking background or even to convert existing images to a combination of 3 and 15 colour sprites so left it at 'bitmap screen can't be wider than 256 pixels' and 4x 15 colour per line on sprites with copper etc

I found a game which would be pretty good to do in BLITZ on AGA with 4 64 pixel 16 colour sprites, it's an old arcade game from 1986 called Super Cross 2. I has 3 colours per characterblock background like NES/Coleco and what look like 32x32 pixel 8 colour sprites for the 4 bike riders on screen. It's sort of like the old C64 game Kickstart meets the game engine of Skidmarks and the gameplay of Excitebike/BMX Kidz.

[ Show youtube player ]

So I thought AGA, 16 colour bitmap (speedy!!) and 4 16 colour sprites. Would make a really nice game for the Amiga, especially if you fix the handling faults the arcade game has!