Bitmaps to sprites in cc65

[+karri]

In the Ubuntu 20.04 there is a new version of Gimp that produce pcx files that seem to crash the sp65 program that does the coversion to sprites.

 

At the same time I realized that it was impossible to generate 8-colour sprites (BPP_3).

 

So I added a new keyword "bpp=3" to the conversion phase.

 

Here is a small tutorial of converting bitmaps to shaped sprites. In order to make my life a little easier I start with a 17 colour bitmap. The last colour is violet that is not included in the default palette.

 

This makes it a bit easier to see the desired shape of the sprite.

 

In order to convert this to a sprite I will use a command line like this:

sp65 -r spr.pcx -c lynx-sprite,mode=shaped,edge=16,ax=32,ay=32 -w spr.c,ident=spr,bytesperline=8

 

This will create a file that defines the sprite like:

#define spr_BPP          4
#define spr_WIDTH        64
#define spr_HEIGHT       64
const unsigned char spr[] = {

 

In the C-code I define the sprite as:

static SCB_REHV_PAL Spr = {
    BPP_4 | TYPE_BACKGROUND,
    PACKED | REHV,
    NO_COLLIDE,
    0,
    spr,
    80, 51,
    0x100, 0x100,
    {0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef}
};

 

 

The result is circular as the violet area was not converted to the sprite.

 

It is also possible to map the colours during the sprite conversion process with the keyword pen=0123456789abcdef

 

Just for fun I now change the mapping to the inverse with

sp65 -r spr.pcx -c lynx-sprite,mode=shaped,edge=16,ax=32,ay=32,pen=fedcba9876543210x -w spr.c,ident=spr,bytesperline=8

 

 

In the next step we want to force the colours to 8 colours only. Without editing the graphics we can map the colours with the keyword bpp=3

 

$(SP) -r spr.pcx -c lynx-sprite,mode=shaped,edge=16,ax=32,ay=32,bpp=3 -w spr.c,ident=spr,bytesperline=8

 

 

Or with bpp=2

 

And finally bpp=1

 

As the last one is a bit dull I could also add the pen-attribute like:

 

$(SP) -r spr.pcx -c lynx-sprite,mode=shaped,edge=16,ax=32,ay=32,bpp=1,pen=0123765489abfedcx -w spr.c,ident=spr,bytesperline=8

[42bs]

Nice feature. Do you mind if  I "borrow" it for sprpck?

[+karri]

14 minutes ago, 42bs said:

Nice feature. Do you mind if  I "borrow" it for sprpck?

Not at all. Please do it.

 

Actually these shaped sprites is the way to go for making patches to old-time carts. If you leave out the "edge" it will default to 0. So this means that even when used on normal sprites you can omit the last stride to the edge of the extent of the sprite if the colour index is 0.

[42bs]

Fine. But with a color > 15 (0..15), it only works if you set an action point, right?

Anyway, I will try.

[+karri]

The action point must be in the middle and you can have no holes in the object. If you have av action point at the edge then you get a black area from the edge to the object.

 

In Titan I used ground shadows to cover the problematic areas.

[42bs]

Ah, it seems the "trick" is to map any color > 15 to 16 and after masking to 0.

[42bs]

BTW:

AssembleByte(ColorBits, LineBuffer[i] & ColorMask);

This masking is redundant as you mask already when writing into LineBuffer.

Edited September 21, 2020 by 42bs

[+karri]

7 hours ago, 42bs said:

BTW:

AssembleByte(ColorBits, LineBuffer[i] & ColorMask);

This masking is redundant as you mask already when writing into LineBuffer.

You would be surprised to see the amount on redundant code I write. On of my bad habits...