How do plus hardware sprites work?

[zhulien]

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

[roudoudou]

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

[Shining]

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.

[andycadley]

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.

[Targhan]

Multiplexing isn't enormously useful

Mmmh, I don't know anything the Plus, but I guess multiplexing is how @norecess displays the many rings in Sonic GX. So multiplexing shouldn't be dismissed lightly .

[TotO]

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 Yes, it allows to display up to 40 rings !!!

[andycadley]

Multiplexed sprites are useful and used (arcade and consoles) to draw weapon bullets, snow layers, common ennemies, ...

@Targhan 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.

[andycadley]

Mmmh, I don't know anything the Plus, but I guess multiplexing is how @norecess 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)

[TotO]

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.

[Targhan]

I 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.

[zhulien]

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.

[roudoudou]

whereas on a Plus you have to write 256 bytes to do it.

this is the worst case, not a rule 

[andycadley]

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.

[roudoudou]

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

[andycadley]

maybe you miss this tech-demo with 3 sprites for bullets...
https://www.cpc-power.com/index.php?page=detail&num=17425

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.

[zhulien]

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. 

[zhulien]

maybe you miss this tech-demo with 3 sprites for bullets...
https://www.cpc-power.com/index.php?page=detail&num=17425

Is there a downloadable version of that demo somewhere? or perhaps youtube video?

[roudoudou]

Is there a downloadable version of that demo somewhere? or perhaps youtube video?

the message you quoted contains a link 

[norecess464]

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?

Scanline.
Like @roudoudou 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).

Is 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.

Can 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 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.

[roudoudou]

Yes for multiplex. Weirdly, this was not exploited during the commercial existence of the GX-4000...

waaaaaaaaaaaaaaaaaaaaaaat?

[dthrone]

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.

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?

[zhulien]

waaaaaaaaaaaaaaaaaaaaaaat?

The trees?

[norecess464]

@roudoudou 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 !

[Optimus]

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.

[zhulien]

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?