Jump to content
drludos

Chaining Sprites with CC65?

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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]); 

 

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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 };

 

 

 

 

Share this post


Link to post
Share on other sites

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.

 

 

 

 

 

 

Share this post


Link to post
Share on other sites
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 by jum

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...