Support for a sprite layer

[sdsnatcheralpha@…]

GrafX2 has support for layers, but it would be nice if a special type of layer able to handle sprite restrictions could be added.

Sprites are used on many platforms (C64, MSX1/2/2+, etc) to hide the color-bleeding, enhancing image quality.

[Philip Linde]

Sprite restrictions seem a bit harder to define than e.g. the restrictions of the plain hi-res mode of the C64. It boils down not only to how many sprites and at what sizes you can display them per line or screen, using how many colors, but also, in some complex image schemes, how quickly and when you can reuse a sprite to draw it again some lines later.

I think that such a special layer might be better solved generally as a "restricted layer" where each drawing operation is verified using a selectable Lua script. For a simple single color sprite overlay this could for example be a layer attached to a script that simply check that the non-transparent data fits in the available sprite slots of the machine. This way it is extensible by the user and can be applied generally to a wide range of image schemes and platforms.

[PulkoMandy]

I'm not sure it's reasonable to do this isn realtime. I thought about it for Amstrad CPC "rasters" (palette changes in sync with the display hardware) and the outcome is, it's good enough to implement only a relaxed partial check of the constraints, and then have more restrictive check when exporting the picture to a specific format, or even just let the developer trying to usethe picture figure things out and iterate.

You can however use a lua script bound to a shortcut, that can easily be triggered, and highlights tho errors (for example by marking them with a specific color in an extra layer). With complex enough constraints, this "check" (rather than "enforce") mode ends up easier to use, because grafx2 wouldn't do a great job at reducing tour drawing tothe hardware constraints in the best way.

[sdsnatcheralpha@…]

Indeed, raster effects would be too complicated to implement. I was thinking of the plain vanilla sprites, without any tricks. Yet simple, they still can produce beautiful results like these:

C64 highres+sprites:
​http://tomseditor.com/gallery/i/6495/sovjet-sentrifug-by-extend&lang=en
​http://tomseditor.com/gallery/i/6235/song-for-the-dead-by-duce&lang=en
​http://tomseditor.com/gallery/i/908/the-origin-of-pixels-by-duce&lang=en

C64 multicolor+sprites:
​http://tomseditor.com/gallery/i/2609/no-shit-by-mermaid-redcrab&lang=en
​http://tomseditor.com/gallery/i/6161/cock-picture-by-ilesj&lang=en
​http://tomseditor.com/gallery/i/36028/unconditional-lover-by-ptoing&lang=en

MSX1 screen2+sprites:
​http://tomseditor.com/gallery/i/52413/nights&lang=en
​http://tomseditor.com/gallery/i/52407/una-escena-feliz-by-viejo-archivero&lang=en
​http://tomseditor.com/gallery/i/35000/malaika&lang=en
​http://tomseditor.com/gallery/i/34975/the-maze-of-galious-title-screen&lang=en

MSX2 screen4+sprites:
​http://tomseditor.com/gallery/i/34520/space-manbow-stage-7-boss&lang=en
​http://tomseditor.com/gallery/i/34522/space-manbow-last-boss&lang=en

[Thomas Bernard]

well using an additional layer for sprites is already possible.
we may introduce sprite restriction but that is not easy.
If I'm thinking about the C64, there are 8 sprites which are either monocolor, or multicolor (3 colors)
Multicolor sprites have 1 color specific for the sprite and 2 which are common

The way GrafX2 is implemented it would be nearly impossible to allow monocolor sprites on a multicolor background :(

[Thomas Bernard]

The MSX .SC2 file loader does load sprites to the layer 2.

I should try to do the same for C64.

Saving will be tricky...