sp65

[obschan]

Hi Karri, I read about the new sp65 on another topic and did not want to hijack the thread.

I am interested, eager to move from sprpck to sp65, I would like a fully portable chain.

What is the status of the current release ?

I just gave a try to the latest svn, but I only succeed to open pcx and it seems to only want to convert to vic2.

Do you have a simple working example of sp65 use for lynx ?

 

Thanks !

[sage]

I am interested, eager to move from sprpck to sp65, I would like a fully portable chain.

 

Sorry for dumb question, but where is sprpck _not_ portable!?

[obschan]

Dont know, havent had a look.

I have 2 systems, one x86 under Windows where sprpck works perfectly.

And an Arm under linux -on which cc65 chain works as expected- which can't read bmps and gives me core dumps.

I guess I could take time to do some debug though ...

[sage]

Dont know, havent had a look.

I have 2 systems, one x86 under Windows where sprpck works perfectly.

And an Arm under linux -on which cc65 chain works as expected- which can't read bmps and gives me core dumps.

I guess I could take time to do some debug though ...

 

just a guess: maybe little/big endian problem?

what endianess is your arm system compiled for?

[+karri]

The sp65 is still not working for the Lynx. I hope to have the time to write the missing pieces during 2012.

 

--

Karri

[obschan]

just a guess: maybe little/big endian problem?

what endianess is your arm system compiled for?

That was a good idea, I checked, both are little.

I went through some debugging and actually this is because of a buffer overrun in the packit function.

The malloc was too small for the generated data. It's possible to generate data bigger than (w+1)*(h+1). (This particular problematic sprite was 1*32)

 

The sp65 is still not working for the Lynx. I hope to have the time to write the missing pieces during 2012.

Ok sounds great Karri, it will help to have a homogeneous tool chain.

Edited October 17, 2012 by obschan

[sage]

That was a good idea, I checked, both are little.

I went through some debugging and actually this is because of a buffer overrun in the packit function.

The malloc was too small for the generated data. It's possible to generate data bigger than (w+1)*(h+1). (This particular problematic sprite was 1*32)

 

Which line?

[obschan]

Which line?

364 on wookie's repo.

https://bitbucket.org/wookie/sprpck/src/29cda5cc3c85535461191eb21b8f98af8e047e5d/sprpck.c?at=default

Let me know if you can confirm.

[sage]

364 on wookie's repo.

Let me know if you can confirm.

 

you replaced (w+1)+h+1 by (w+1)(*(h+1) ?

anyway, just increase the malloc value should work, as this (most likely) only happens if the packed data is (much) larger than the raw data.

remember that the original software was for 1MB machines

[obschan]

Yes exactly, the packed data were larger than the raw.

I did something dirty ((w+1)*h+1) * 10 ... but that corrected instantly my core dump.

The bug never shown up in Windows though.

Edited October 27, 2012 by obschan

[+karri]

The first version of sp65 in now in the svn.

 

The syntax for using it is like:

 

$(CP) $(CC65_HOME)/tgi/lynx-160-102-16.tgi .
$(CO) --code-label _lynxtgi lynx-160-102-16.tgi
$(AS) -t lynx lynx-160-102-16.s
$(SP) -r Tree.pcx -c lynx-sprite -w Tree.c,ident=Tree
$(CC) -t lynx Tree.c
$(AS) -t lynx Tree.s
$(CC) -t lynx main.c
$(AS) -t lynx main.s
$(CL) -t lynx -o game.lnx main.o Tree.o lynx-160-102-16.o lynx.lib

 

Here is a small piece of the Tree.c generated by sp65.

/*
* This file was generated by sp65 2.13.9 from
* Tree.pcx (45x51, 15 colors, indexed)
*/

#define Tree_COLORS	 15
#define Tree_WIDTH	 45
#define Tree_HEIGHT	 51
const unsigned char Tree[] = {
0x18,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x44,0x44,0x44,0x44,0x4C,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x18,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

 

And finally how you use it from C-code:

extern unsigned char Tree[];

sprite_t introSprite = {
 SPRCTL0_4_bits_per_pixel | SPRCTL0_normal,
 SPRCTL1_literal | SPRCTL1_hsize_vsize,
 SPRCOLL_dont_collide,
 0,
 &Tree,
 0, 0,
 0x100, 0x100,
 0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef
};

void main(void) {
tgi_install(&lynxtgi);
tgi_init();
CLI();
while (tgi_busy())
;
tgi_clear();
tgi_setcolor(COLOR_PINK);
tgi_bar(0, 0, 159, 101);
tgi_sprite(&introSprite);
tgi_updatedisplay();
while (1)
;
}

 

And the first sprite on screen:

[obschan]

Thank you Karri, sounds great.

I'll give it a try.

Cheers.

[+karri]

Well, so far I have only implemented totally literal sprites. There will still be packed sprites and also transparent sprites. The last one is a packed sprite where all unnecessary transparent pixels are removed from the left and right edges of the sprite. It may be a few bits smaller.

 

But there still remains to set the anchor point of the sprite and output the palette in Lynx format.

 

The only supported input file type today is pcx. But that will also change later.

--

Karri

[+karri]

One detail to programmers. Shawn Jefferson contributed with a file called _suzy.h. It is automatically included by lynx.h. Inside that file you can find pre-defined sprite structures like:

 

typedef struct SCB_REHVST_PAL {			 // SCB with all attributes
 unsigned char sprctl0;
 unsigned char sprctl1;
 unsigned char sprcoll;
 char *next;
 char *data;
 unsigned int hpos;
 unsigned int vpos;
 unsigned int hsize;
 unsigned int vsize;
 unsigned int stretch;
 unsigned int tilt;
 unsigned char penpal[8];
} SCB_REHVST_PAL;

typedef struct SCB_RENONE {				 // SCB w/o size/stretch/tilt/pal
 unsigned char sprctl0;
 unsigned char sprctl1;
 unsigned char sprcoll;
 char *next;
 char *data;
 unsigned int hpos;
 unsigned int vpos;
} SCB_RENONE;

 

There is also symbolic names for all the sprite control values:

/* SPRCTL0 $FC80 */
#define BPP_4		    0xC0
#define BPP_3		    0x80
#define BPP_2		    0x40
#define BPP_1		    0x00
#define HFLIP		    0x20
#define VFLIP		    0x10
#define TYPE_SHADOW	  0x07
#define TYPE_XOR		 0x06
#define TYPE_NONCOLL	 0x05
#define TYPE_NORMAL	  0x04
#define TYPE_BOUNDARY    0x03
#define TYPE_BSHADOW	 0x02
#define TYPE_BACKNONCOLL 0x01
#define TYPE_BACKGROUND  0x00

[obschan]

Ok got it, one feature which is quite cool on sprpck is its 'tiles' mode, very useful.

[+karri]

Ok got it, one feature which is quite cool on sprpck is its 'tiles' mode, very useful.

 

I know. In the sp65 there is a crop functionality to cut out an area but so far no tiles mode.

 

--

Karri

[LX.NET]

Great stuff as always.

My feature request list is:

- Windows Bitmap support

- Tiles (like obschan mentioned)

- Choice of packed/literal

- Turn off optimizations you mentioned

- Reference/action point

- Ability to parametrize all of the above

- (?) Classic mode to support older codebases (makes it behave like sprpck a bitin outputting a .spr file, but I guess that in the light of sp65 being part of cc65 this might make less sense)

Thanks. I'll try it later.

[obschan]

Great stuff as always.

My feature request list is:

Thanks. I'll try it later.

 

Off topic subliminal message for LX.NET "aaa~and an~~ accuuu~~rateeee~~~ emuuu~~~~latoooooor ..."

[LX.NET]

I suddenly remembered that I need to work on accurate emulation some more.

Maybe a private release would help.

[+karri]

About the new syntax for sp65.

 

The command line can be breaked into three areas:

- input

- processing

- output

 

The input is like

 

-r Tree.pcx

or

-r Tree.pic,format=pcx

 

The processing part is like

 

-c lynx-sprite,mode=literal,ax=10,ay=20

 

this affects the packing mode and action point placement in the sprite

 

The output part

 

-w Tree.spr,format=bin

 

or

 

-w Tree.c,ident=Tree,bytesperline=8

 

So a complete command looks like this:

 

sp65 -r Tree.pcx -c lynx-sprite,ax=25,ay=41 -w Tree.c,ident=Tree

 

In the future I can imagine to add automatic tiling to the input part like:

 

offx=20,offy=0,tilewidth=16,tileheight=32,xtiles=22,ytiles=4

 

And in the output part some special characters to indicate naming of the tiles like

 

ident=Tree%%%

 

Is this getting too complicated?

 

--

Karri

Edited November 7, 2012 by karri

[obschan]

I don't think it's too complicated, it looks good and structured.

We need a way to input those params anyway.

[+karri]

Now the sp65 has three basic modes:

 

mode=literal

mode=packed

mode=shaped (a packed sprite with edges cut off)

 

This last mode is something I found while reading the docs. You can end a scanline with 5 zero bits and shape the right edge of the sprite.

 

 

The cool thing is that the sprite does not need transparent colors in this mode.

 

Well, it appears to work for the left edge as well if the action point ax is somewhere in the middle.

 

 

There seems to be a lot of bugs in this mode still...

 

I still have to develop some cost analysis algorithm for choosing when to use packed and when to use packed literal. The algorithm in sprpck is not very good. It very often produces larger sprites in packed mode than in literal mode. Especially when using 1-bit deep sprites.

--

Karri

Edited November 12, 2012 by karri

[obschan]

Thank you for the update Karri.

 

The cool thing is that the sprite does not need transparent colors in this mode.

Well, it appears to work for the left edge as well if the action point ax is somewhere in the middle.

Yes it sounds great, I am using it too, I am wondering which mode is quicker though, in this mode we have to change the drawing direction 1 to 3 times.

Edited November 13, 2012 by obschan

[+karri]

Yes it sounds great, I am using it too, I am wondering which mode is quicker though, in this mode we have to change the drawing direction 1 to 3 times.

 

No idea. Once I get the output to work correctly in all three modes I could do some measurements.

 

My feeling is that "shaped" is the fastest as a lot of pixels are cut out in the case of the Tree sprite.

[obschan]

No idea. Once I get the output to work correctly in all three modes I could do some measurements.

Am very interested in the results.