obschan Posted October 16, 2012 Share Posted October 16, 2012 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 ! Quote Link to comment Share on other sites More sharing options...
sage Posted October 16, 2012 Share Posted October 16, 2012 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!? Quote Link to comment Share on other sites More sharing options...
obschan Posted October 16, 2012 Author Share Posted October 16, 2012 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 ... Quote Link to comment Share on other sites More sharing options...
sage Posted October 16, 2012 Share Posted October 16, 2012 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? Quote Link to comment Share on other sites More sharing options...
+karri Posted October 17, 2012 Share Posted October 17, 2012 The sp65 is still not working for the Lynx. I hope to have the time to write the missing pieces during 2012. -- Karri Quote Link to comment Share on other sites More sharing options...
obschan Posted October 17, 2012 Author Share Posted October 17, 2012 (edited) 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 Quote Link to comment Share on other sites More sharing options...
sage Posted October 17, 2012 Share Posted October 17, 2012 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? Quote Link to comment Share on other sites More sharing options...
obschan Posted October 17, 2012 Author Share Posted October 17, 2012 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. Quote Link to comment Share on other sites More sharing options...
sage Posted October 26, 2012 Share Posted October 26, 2012 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 Quote Link to comment Share on other sites More sharing options...
obschan Posted October 27, 2012 Author Share Posted October 27, 2012 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+karri Posted November 3, 2012 Share Posted November 3, 2012 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: Quote Link to comment Share on other sites More sharing options...
obschan Posted November 5, 2012 Author Share Posted November 5, 2012 Thank you Karri, sounds great. I'll give it a try. Cheers. Quote Link to comment Share on other sites More sharing options...
+karri Posted November 5, 2012 Share Posted November 5, 2012 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 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted November 5, 2012 Share Posted November 5, 2012 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 Quote Link to comment Share on other sites More sharing options...
obschan Posted November 5, 2012 Author Share Posted November 5, 2012 Ok got it, one feature which is quite cool on sprpck is its 'tiles' mode, very useful. Quote Link to comment Share on other sites More sharing options...
+karri Posted November 5, 2012 Share Posted November 5, 2012 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 Quote Link to comment Share on other sites More sharing options...
LX.NET Posted November 5, 2012 Share Posted November 5, 2012 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. Quote Link to comment Share on other sites More sharing options...
obschan Posted November 6, 2012 Author Share Posted November 6, 2012 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 ..." Quote Link to comment Share on other sites More sharing options...
LX.NET Posted November 6, 2012 Share Posted November 6, 2012 I suddenly remembered that I need to work on accurate emulation some more. Maybe a private release would help. Quote Link to comment Share on other sites More sharing options...
+karri Posted November 7, 2012 Share Posted November 7, 2012 (edited) 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 Quote Link to comment Share on other sites More sharing options...
obschan Posted November 7, 2012 Author Share Posted November 7, 2012 I don't think it's too complicated, it looks good and structured. We need a way to input those params anyway. Quote Link to comment Share on other sites More sharing options...
+karri Posted November 12, 2012 Share Posted November 12, 2012 (edited) 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 Quote Link to comment Share on other sites More sharing options...
obschan Posted November 12, 2012 Author Share Posted November 12, 2012 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+karri Posted November 13, 2012 Share Posted November 13, 2012 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. Quote Link to comment Share on other sites More sharing options...
obschan Posted November 13, 2012 Author Share Posted November 13, 2012 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.