drludos Posted June 18, 2019 Share Posted June 18, 2019 Hi! I'm slowly starting to discover the wonderful world of LynxDev thanks to Karri's version of CC65 and LX.net tutorial. I managed to display several sprites on screen, but I was wondering: How can we "chain" sprites to speed up their drawing? I declare my SCB in separate variables, like the following example : extern unsigned char gfx_bg[]; SCB_REHV_PAL spr_bg = { BPP_4 | TYPE_BACKGROUND, REHV, NO_COLLIDE, 0, gfx_bg, 0, 0, 0x0100, 0x100, { 0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF } }; But, when I try to add the variable name of another SCB (say "spr_player") in the "next" member of the struct, I get a compilation error. I've tried to insert a reference to it (&spr_player), but it doesn't work either. I looked at the various examples on this forum, but the ones I found use some ASM code to make the SCB chain. So, how can we chain SCB with CC65? Thanks for your help! Quote Link to comment Share on other sites More sharing options...
Nop90 Posted June 18, 2019 Share Posted June 18, 2019 simply cast the next sprite pointer to (char *) This is how I initialize my chain (loop omitted): sp_changes[i].next = (char*) &(sp_changes[i+1]); Quote Link to comment Share on other sites More sharing options...
drludos Posted June 18, 2019 Author Share Posted June 18, 2019 It works perfectly, thanks a lot Nop90! By-the-way, thanks a lot for your update template too, it's very very helpful to start making your first lynx game! I'm looking forward to your entry in the competition! Quote Link to comment Share on other sites More sharing options...
jum Posted June 20, 2019 Share Posted June 20, 2019 This is how I have my SCB struct defined: // Lynx Sprite Control Block structure typedef struct SCB { uchar sprctl0; uchar sprctl1; uchar sprcoll; // spr collision number struct SCB *next; uchar *data; signed int hpos; signed int vpos; uint hscale; uint vscale; uchar palmap[8]; uint collResult; // collision result data (offset = 23) } TSCB; Note "struct SCB *next;". This allows us to reference the next SCB without casting, like so: struct SCB clearSCB = { 0xc0, // 4bpp / bg_no_collision 0x10, // compressed, hsize/vsize 0x00, // 0 to clear coll buffer &playerSCB, sprclr, 0x100, 0x100, 0xa000, 0x6600, { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef }, 0 }; Quote Link to comment Share on other sites More sharing options...
Nop90 Posted June 20, 2019 Share Posted June 20, 2019 Can't see the problem of using such a cast: a cast to a different pointer type is only overriding a compiling check, it has no performance effects. The drawback of your struct is that it expects to chain always sprites of the same type (in this case a full sprite with scale info, palette and collision data) while haveing a field with a pointer to a generic char array allow you to chain different sprites types, that in the end can make you save memory. I can immagine that in a complex scene one could use a mix of simple sprites and scaled ones, and saving some bytes is often very important. As a basic example of this, I use to make start the chain with sprite with a palette, than make all the others reuse the palette of the first. Yes, you can chain different sprites defining different structs and using a cast only when needed, but IMHO it's not a clean solution in terms of code readability. Hope to not seem rude, I don't want criticize you code. Often I wrote ugly code if it works at first try. I'm only giving my 2 cents to encourage the discussion. Quote Link to comment Share on other sites More sharing options...
jum Posted June 21, 2019 Share Posted June 21, 2019 (edited) On 6/20/2019 at 12:34 PM, Nop90 said: The drawback of your struct is that it expects to chain always sprites of the same type (in this case a full sprite with scale info, palette and collision data) while having a field with a pointer to a generic char array allow you to chain different sprites types, that in the end can make you save memory. Hope to not seem rude, I don't want criticize you code. Often I wrote ugly code if it works at first try. I'm only giving my 2 cents to encourage the discussion. No offense taken It's just an alternative way to set up simple SCB chain. You could also save 8 bytes per sprite by leaving the palette mapping out of your SCB struct, and manually setting the palette mapping before drawing the sprite chain. Depends on what you are doing, how many sprites you have, etc. Edited June 21, 2019 by jum 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.