How do plus hardware sprites work?

[Optimus]

Sprites 8 to 15 are all the same, i am guessing it was just faster to process than multiplex the 1 sprite all the way down the trunk? or... that is the limit of trees display on a horizontal?

You also have 4 palm treees horizontally, so maybe each trunk sprite is 8,9,10,11 on X, then repeated position (or maybe repeats the 12,13,14,15 and then back on 8,9,10,11 on 3rd row, etc.. to avoid artifacts?)

[Optimus]

Another funny thing I noticed (but makes sense how the HW sprites works together with the CRTC emulation?), if you make a hardware split with CRTC this will affect the rendering of hw sprites based on position. So, if you do a single char split so the lines 0-7 always repeat (like I did in my GX8K final part, first time I ever coded CRTC splits ) then place a sprite at zero Y and you will see it repeat inside every charline. Previously I thought they would be independent of CRTC splits. So unfortunately can't make hardware split screens without you having to manually manipulate the sprite vertical positions frequently. I don't know if this is an exception with the CPC+ single split provided (where you avoid to do it the old plain CPC way).

[andycadley]

Another funny thing I noticed (but makes sense how the HW sprites works together with the CRTC emulation?), if you make a hardware split with CRTC this will affect the rendering of hw sprites based on position. So, if you do a single char split so the lines 0-7 always repeat (like I did in my GX8K final part, first time I ever coded CRTC splits ) then place a sprite at zero Y and you will see it repeat inside every charline. Previously I thought they would be independent of CRTC splits. So unfortunately can't make hardware split screens without you having to manually manipulate the sprite vertical positions frequently. I don't know if this is an exception with the CPC+ single split provided (where you avoid to do it the old plain CPC way).

If you use the Plus screen split the sprites behave the way you would expect. And it doesn't have to be a single split, since you can also reprogram that register on the fly to manage multiple splits on the screen.


As to the question of emulation, a lot of real quirks on the hardware don't show up in emulators as of yet, so you really do have to try things out on the real machine to see how it actually looks.


Not being able to repoint a sprite is definitely one of the weak points of the design, although being able to disable all sprites as part of a screen split is the feature I would most dearly have loved.

[norecess464]

Exactly. If you want your ASIC sprites to play nicely as expected between the screen splits, and avoid unexpected behavior like bottom clipping on sprites when crossing new splits, you are better to rely on hardware SPLT, and not "fake yourself" splits using directly the CRTC. To keep it simple, ASIC and CRTC programming are mutually bad friends together!

[Optimus]

Exactly. If you want your ASIC sprites to play nicely as expected between the screen splits, and avoid unexpected behavior like bottom clipping on sprites when crossing new splits, you are better to rely on hardware SPLT, and not "fake yourself" splits using directly the CRTC. To keep it simple, ASIC and CRTC programming are mutually bad friends together!

Damn, I didn't know that! And I was fighting LOL. The split was a routine I tried previously on plain CPC and just ported anyway.
Good to know you can also move the split many times, because previously I was under the impression that it was restricted to one split, but didn't even attempted to test this assumption anyway.

[norecess464]

@Optimus There are many sources to learn ASIC programming, but only one that you can really trust: the official Specs from Amstrad, with some extra annotations from @arnoldemu and @Executioner (once the rev. 1.5) : https://www.cpcwiki.eu/index.php/Arnold_V_Specs_Revised . If you read it and that something is not clear enough, then re-re-re-read it till it gets clear enough to you

Then, read that doc: http://www.cpcwiki.eu/index.php?title=Plus_Vectored_Interrupt_Bug
With those 2 docs combined, you can do EVERYTHING you want with the ASIC. Please note that none of them talk about reprogramming by yourself the CRTC ;-) Eventually, only R12-R13 matters for the 1st (original) screen, of course R1/R2/R6/R7 too, but that's all. Don't touch R4/R7 etc etc.

Finally, another reference is studying Eerie Forest from @Overflow  (yes, him again !). There is the source-code directly in the archive, so you can have some look and learn from it.. https://www.cpc-power.com/index.php?page=detail&num=14939 . From there, for example you can see that Overflow reserves the secondary Z80 register set for the rasters (background colors fading) managed through PRI interrupts, this approach was useful to me to gain some precious NOPs in Sonic GX...

Combined, both Eerie Forest and CRTC3 from @roudoudou got me motivated to try myself stuff for the ASIC in first place. Then, the great Ghost'n'Goblins from @Xifos convinced me to make Sonic GX !

[norecess464]

Good to know you can also move the split many times, because previously I was under the impression that it was restricted to one split, but didn't even attempted to test this assumption anyway.

Even better, think about it: you can simulate the traditional RVI addressing all the VRAM with the ASIC by reprogramming each scanlines: 1) the next SPLT  2) the next R12-R13 to select (via SSA)  3) the first scanline in character to display via SSCR (cf. in other words, which "C9" / "VLC" to use / start your screen with).
Nothing new here, @roudoudou did it with his "Rouleau de Printemps" (https://www.cpc-power.com/index.php?page=detail&num=16079), an under-rated prod that was definitively a "first" for the platform !

[sigh]

But, the ASIC features 16 (SIXTEEN !) hardware sprites, which is pretty great when compared to the C64's 8 hardware sprites.

But aren't these limited in size unlike the C64?

[andycadley]

But aren't these limited in size unlike the C64?

They're limited to 16*16 pixels, at various magnifications. So, unfortunately, smaller than C64 sprites.

[TotO]

But aren't these limited in size unlike the C64?

The C64 sprites are limited in size too.
X=24, Y=21, Z=1 with ratio 1:1 (1 colour like The Last Ninja)
X=24, Y=21, Z=2 with ratio 2:1 (3 colours like most games)

The PLUS sprites are X=16, Y=16, Z=4 (15 colours) into any ratio/zoom mode.

[andycadley]

The C64 sprites are limited in size too.
X=24, Y=21, Z=1 with ratio 1:1 (1 colour like The Last Ninja)
X=24, Y=21, Z=2 with ratio 2:1 (3 colours like most games)

The PLUS sprites are X=16, Y=16, Z=4 (15 colours) into any ratio/zoom mode.

The C64 can do double width or height so can cover a much larger area (at the expense of lower resolution).


The Plus can do *2 or *4 in both vertical and horizontal direction, but that's assuming Mode 2 sized pixels (i.e. 4* horizontal zoom is only 16 Mode 0 pixels wide).