CPCTelera : CPC+ Sprite Hardware

[Arnaud]

Hello,
here a little demo of the implementation of the CPC+ Sprite Hardware in CPCTelera.

I'm now working to make the code as comprehensible as possible (asm and example) before release it (here and on a Github CPCTelera branch).


On the screnshot 22 colors are used in mode 1 
Hardware Sprites are really easy to use and can be mixed on screen with "classical" software Sprites in the same time.

Arnaud

For more detailled informations on HW Sprites : http://www.chibiakumas.com/z80/platform4.php#LessonP32

[XeNoMoRPH]

https://vimeo.com/350579592
Awesome Smooth sprites !!!  ,

I have captured it on video

[Arnaud]

Great to make this video 

Honestly, the CPC+ makes all the work.

[asertus]

It's a pity this sprite support was not in the original 464, or at least in the 6128, the MSX2 were done those things quite well..

[TotO]

The shame is that PLUS sprites requires to copy data (byte) instead of updating address pointers.
The MSX had poor sprites (1 bit, 4 per raster line) and not descent screen scrolling at all.

By the way, the CPC was more close to a PC than a MSX/Coleco into its design and had been better to have blitting functions to do what we want with our imaginations, instead to be limited by a fixed sprite system that conditions the types of games, demo, ... you can program with them.

[zhulien]

I wonder if then, if a small genlock circuit can be made with hardware sprites external to the CPC RAM, but genlocked into the display before output to the screen?  Maybe not just sprints, but copper functions and perhaps even display lists.

[TotO]

I wonder if then, if a small genlock circuit can be made with hardware sprites external to the CPC RAM, but genlocked into the display before output to the screen?  Maybe not just sprints, but copper functions and perhaps even display lists.

Sure. Or best, a Graffiti like display system.

[zhulien]

Sure. Or best, a Graffiti like display system.

That is actually a good idea for a future CPC generation, but in a way so that existing CPC owners can buy a CPC-Graffiti as an option

[norecess]

The shame is that PLUS sprites requires to copy data (byte) instead of updating address pointers.

Actually, it's not that bad! Updating a sprite the lame way (cf. without using advanced techniques) using 256 LDIs takes 256*5 NOPs = 1280 NOPs, which represents 6.4% of available CPU time for 1 frame (19968 NOPs).

Tip: If you have let's say 4 sprites to update, and if your game design allows it, then use 4 frames to update 1 sprite (instead of 1 frame updating 4 sprites).

[TotO]

Sure, the limitations are always the best challenges to produce some clever codes. We love "CPC" for that.

[andycadley]

Yeah, it's really only awkward from a multiplexing point of view, because you can't easily re-use a sprite unless the image is the same as a previous one. Or unless they are far enough apart and your timing pretty good.

[Arnaud]

Update :
- All my functions are nearly finished and commented and i have added "Raster lines interrupt" feature, now there are 34 colors for Mode 1 
- Finally my demo became a little game, we have to escape from the Asteroid Field (my five years old son really like it )

Arnaud

[Ast]

@Arnaud : you'll have to find a tittle now   

[Arnaud]

Hi,
here the CPCtelera project (v1.5) for CPC+ Sprite Hardware :
- Game demo in cpcplus/src
- Asic functions in cpcplus/src/asic

And tested on real CPC Plus.

All remarks are welcome 

Next step is to send to a branch in Github/cpctelera

cpcplus_src.zip
(84.96 kB - downloaded 1 times)