Hi
I am curious to know how plus hardware sprites work.
I know they are memory mapped likely inside memory contained within ASIC.
Upon a screen refresh of normal video memory what is the order of hardware operations that occur for hawdware sprites to render?
Are they rendered in frame? Within the scanline? Is the memory mapped ram read even if a hardware sprite is at a particular overlapping pixel?
Can plus hardware sprites be multiplexed? Has anyone worked out the per scan line limitations or timings to multiplex?
Thanks
you may change sprite data/coordinates anytime, even during display of it (some side effects)
there is almost instant refresh of all sprites, you may display the same sprite many times on a single line if you want (but this will be very time consuming)
sprite data is always from Asic RAM
Yes, as roudoudou says. Also you can, like with the normal display, change the sprite palette during the screen is painted.
Like in the beer part in my schnapps demo. There the sprites are reused at the bottom with a different palette.
Also you can use a different sprite-zoom-factor for the multiplexed sprites.
Yes, the normal video operations occur exactly as if the sprites weren't present. The ASIC internally decides if a pixel is obscured by a hardware sprite and, if so, changes the colour pixel being output.
You can certainly multiplex them and even chop them up by moving them during the part of the screen where they would be displayed. Iirc changing a sprites registers temporarily turns it off during the write, but it's probably in the Arnold V documentation. Multiplexing isn't enormously useful, as it is on say the C64, because you still need to write a new image into the ASIC registers and that's not as quick as one would like.
Quote from: andycadley on 12:58, 22 August 21
Multiplexing isn't enormously useful
Mmmh, I don't know anything the Plus, but I guess multiplexing is how @norecess (https://www.cpcwiki.eu/forum/index.php?action=profile;u=2409) displays the many rings in Sonic GX. So multiplexing shouldn't be dismissed lightly :).
Quote from: andycadley on 12:58, 22 August 21
Multiplexing isn't enormously useful, as it is on say the C64, because you still need to write a new image into the ASIC registers and that's not as quick as one would like.
Multiplexed sprites are useful and used (arcade and consoles) to draw weapon bullets, snow layers, common ennemies, ...
@Targhan (https://www.cpcwiki.eu/forum/index.php?action=profile;u=110) Yes, it allows to display up to 40 rings !!!
Quote from: TotO on 13:43, 22 August 21
Multiplexed sprites are useful and used (arcade and consoles) to draw weapon bullets, snow layers, common ennemies, ...
@Targhan (https://www.cpcwiki.eu/forum/index.php?action=profile;u=110) Yes, it allows to display up to 40 rings !!!
I meant very specifically in the case of the Plus hardware. On other machines it's obviously enormously useful, but most other machines making swapping a sprites visual representation very fast, whereas on a Plus you have to write 256 bytes to do it.
Quote from: Targhan on 13:29, 22 August 21
Mmmh, I don't know anything the Plus, but I guess multiplexing is how @norecess (https://www.cpcwiki.eu/forum/index.php?action=profile;u=2409) displays the many rings in Sonic GX. So multiplexing shouldn't be dismissed lightly :) .
The specific case of displaying many rings, where all the multiplexed sprites look the same is one of the cases where you can more easily bend the hardware to do what you want.
On a C64, for example, though you might use the same sprite for the top and bottom half of a play character which is nigh on impossible on the Plus hardware (unless you have insanely precise timing)
The multiplexing is not related to the sprite data update. So, if your game already update the sprites (not at the same frame) to make something animated, instead of displaying one, you are displaying more.
Quote from: andycadley on 14:23, 22 August 21I meant very specifically in the case of the Plus hardware.
The Plus might be limited compared to other hardware, but imagine a shooter with many, many, sprites, thanks to multiplexing (bullets, or enemies). So, one must not think about the weakness, but how the feature can be used in an awesome way.
I was actually thinking if a game like Recca for NES could be possible on a plus. I guess for waves of the same enemies that should work well. And if animations are kept sparingly we may only need to update actual sprite data between waves.
Quote from: andycadley on 14:23, 22 August 21
whereas on a Plus you have to write 256 bytes to do it.
this is the worst case, not a rule ;D
Quote from: Targhan on 14:43, 22 August 21
The Plus might be limited compared to other hardware, but imagine a shooter with many, many, sprites, thanks to multiplexing (bullets, or enemies). So, one must not think about the weakness, but how the feature can be used in an awesome way.
I'm a massive fan of the Plus hardware, I certainly think it has enormous scope for achieving things beyond how far it has been pushed so far. I'm also quite willing to admit it has some weaknesses compared to other machines (those the tradeoffs aren't all one way, the advantage to having the sprites defined the way they are on the Plus is that there aren't sprite-on-a-line limitations like there are on other machines for example)
If you can find a way to make multiplexed sprites work in your game then definitely go for it, but even if you can't it certainly doesn't make them useless either.
Quote from: andycadley on 16:49, 22 August 21
If you can find a way to make multiplexed sprites work in your game then definitely go for it, but even if you can't it certainly doesn't make them useless either.
maybe you miss this tech-demo with 3 sprites for bullets...
https://www.cpc-power.com/index.php?page=detail&num=17425
(https://i.postimg.cc/FK77F4XH/grouik.png)
Quote from: roudoudou on 17:17, 22 August 21
maybe you miss this tech-demo with 3 sprites for bullets...
https://www.cpc-power.com/index.php?page=detail&num=17425 (https://www.cpc-power.com/index.php?page=detail&num=17425)
(https://i.postimg.cc/FK77F4XH/grouik.png)
I'd not seen that particular one, but I had my own multiplexer that would attempt to juggle sprites around so they could be reused for a shoot em up that never went anywhere.
The trick was having enemies use different animation frames so that all the frames would be "in use" at the same time you'd just cycle which ones were assigned to which enemies. And occasionally drop frames on a cyclic basis (like a lot of GB sprite engines) so if the screen got too busy everything would still work but a flicker slightly.
Quote from: andycadley on 17:50, 22 August 21
The trick was having enemies use different animation frames so that all the frames would be "in use" at the same time you'd just cycle which ones were assigned to which enemies. And occasionally drop frames on a cyclic basis (like a lot of GB sprite engines) so if the screen got too busy everything would still work but a flicker slightly.
Actually that is a great idea that I didn't see before applying to hardware sprites (software sprites would be the norm). Imagine each spaceship having 3 frames of animation, moving forward, bank left/bank right. instead of updating the sprite data, re-assign the frame from the bank of available sprites that can be multiplexed.
Quote from: roudoudou on 17:17, 22 August 21
maybe you miss this tech-demo with 3 sprites for bullets...
https://www.cpc-power.com/index.php?page=detail&num=17425
(https://i.postimg.cc/FK77F4XH/grouik.png)
Is there a downloadable version of that demo somewhere? or perhaps youtube video?
Quote from: zhulien on 00:11, 23 August 21
Is there a downloadable version of that demo somewhere? or perhaps youtube video?
the message you quoted contains a link :laugh:
Quote from: zhulien on 11:59, 22 August 21Upon a screen refresh of normal video memory what is the order of hardware operations that occur for hawdware sprites to render?
Quote from: zhulien on 11:59, 22 August 21Are they rendered in frame? Within the scanline?
Scanline.
Like @roudoudou (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1714) mentioned, hardware sprites "follows" the canon beam (like a typical "raster"). At each iterations, the ASIC sprite coordinates / properties / etc and reevaluated, so you can make funny things like multiplexing (change X/Y positions, scaling, etc).
Quote from: zhulien on 11:59, 22 August 21Is the memory mapped ram read even if a hardware sprite is at a particular overlapping pixel?
Yes. The overlapping is defined by sprite order, cf. Sprite0 will overlap Sprite1, that will overlap Sprite2, etc etc. The pen0 is used for transparency, so a sprite can use pen1-15.
There is an issue with memory writes. If you update the sprite's content while it's being rendered, some white artifacts can appear, because the ASIC is busy writing so it can't read the value back. So you are better to update a sprite before it's being rendered.
Also, please note that memory location is fixed. Unlike the C64 where you define which memory location is used for a sprite, the ASIC uses #4000 for Sprite0, #4100 for Sprite1, etc. This is a severe limitation because it implies developer must update the sprite's content or switch to another sprite to do animation. While the sprite's data is 256-bytes large in memory, of course the trick here is to update only the bytes that changed.. updating sprites on a 25hz basis instead of 50hz is also another workaround.
Quote from: zhulien on 11:59, 22 August 21Can plus hardware sprites be multiplexed? Has anyone worked out the per scan line limitations or timings to multiplex?
Yes for multiplex. Weirdly, this was not exploited during the commercial existence of the GX-4000... the tech-demo from @Overflow (https://www.cpcwiki.eu/forum/index.php?action=profile;u=695) referenced above with all those bullets displayed on screen is the best example that comes to me. SonicGX also makes uses of sprite multiplexing to display rings.
Note that sprite positions are based on "Mode 2 sprite pixels", which means X value can be > 255, so it's 2 bytes to update. When you start playing with sprites being dynamically re-positioned during the frame display, updating 3 bytes (2 for X, 1 for Y) on a scanline basis starts to become loud to manage. So here again, there are different strategies to ease the process (avoid to update all values at the same time, etc).
--
Now going further... I would like to point things that really sucks with the ASIC sprites (when compared to traditional consoles):
- inability to define a memory location
- inability to mirror / vertical flip a sprite
But, the ASIC features 16 (SIXTEEN !) hardware sprites, which is pretty great when compared to the C64's 8 hardware sprites.
Quote from: norecess on 13:58, 23 August 21
Yes for multiplex. Weirdly, this was not exploited during the commercial existence of the GX-4000...
waaaaaaaaaaaaaaaaaaaaaaat?
(https://cpcrulez.fr/img/565.png)
:P
Quote from: norecess on 13:58, 23 August 21There is an issue with memory writes. If you update the sprite's content while it's being rendered, some white artifacts can appear, because the ASIC is busy writing so it can't read the value back.
I see this issue on real GX but not in Winape so I don't think this effect is included in the emulation. Are any plus emulators taking this into account?
Quote from: roudoudou on 14:14, 23 August 21
waaaaaaaaaaaaaaaaaaaaaaat?
(https://cpcrulez.fr/img/565.png)
:P
The trees?
@roudoudou (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1714) I was curious so I checked :) (see attached screenshot). I always thought there was no sprite multiplexing in that screen. But now I see you are right :) Elmar stored 2 entire palms (to get the 2 trees at same level) and yes indeed make use of multiplexing. Good catch !
I always thought "sprite multiplexing" means to draw more than the theoritical max on the screen by changing the sprite positions at certain rasterlines. I thought that was the main definition even on C64. I know the C64 can change the address or something while the CPC+ uses the same sprite, but I never thought that as the definition of multiplexing so like when I read on the wiki. Even with just changing positions and other stuff it's still very powerful.
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?
Quote from: zhulien on 16:57, 23 August 21
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?)
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 :P ) 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).
Quote from: Optimus on 17:07, 23 August 21
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 :P ) 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.
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! :P
Quote from: norecess on 18:13, 23 August 21
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! :P
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.
@Optimus (https://www.cpcwiki.eu/forum/index.php?action=profile;u=39) 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 (https://www.cpcwiki.eu/forum/index.php?action=profile;u=122) and @Executioner (https://www.cpcwiki.eu/forum/index.php?action=profile;u=17) (once the rev. 1.5) : https://www.cpcwiki.eu/index.php/Arnold_V_Specs_Revised (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 (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 (https://www.cpcwiki.eu/forum/index.php?action=profile;u=695) (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 (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 (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1714) got me motivated to try myself stuff for the ASIC in first place. Then, the great Ghost'n'Goblins from @Xifos (https://www.cpcwiki.eu/forum/index.php?action=profile;u=186) convinced me to make Sonic GX ! :)
Quote from: Optimus on 18:16, 23 August 21Good 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 (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1714) did it with his "Rouleau de Printemps" (https://www.cpc-power.com/index.php?page=detail&num=16079 (https://www.cpc-power.com/index.php?page=detail&num=16079)), an under-rated prod that was definitively a "first" for the platform ! :)
Quote from: norecess on 13:58, 23 August 21
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?
Quote from: sigh on 10:14, 24 August 21
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.
Quote from: sigh on 10:14, 24 August 21
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.
Quote from: TotO on 14:50, 24 August 21
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).