Jump to content
  • 0

Any trickiness to using CC65 with VERA Sprites?



Probably a dumb question.  I've done VERA sprite programming in BASIC, and now I logically want to do it in C with CC65.

I will peek through the X16 library for CC65, but offhand is there any convenience stuff for doing this? 

Is my C sprite code going to end up looking like my BASIC sprite code?

I've loaded a font file directly to VERA in C, so I figure I can do that to load sprite data directly as well, right?

Anything else I should be considering?

Edited by rje
Link to comment
Share on other sites

3 answers to this question

Recommended Posts

  • 0

I tend not to like convenience functions for things like that. By their very nature, the registers themselves ARE the API in a sense - albeit a very very rudimentary one, but anything built above that is going to steer the project into a direction which may or may not coincide with where you want to go....

As such, my use of cx16.h tends to be mostly in the form of the predefined structs / memory address labels.

e.g.: vera.data0 = 14;

There's no abstraction for sprites above that as far as I'm aware. e.g. no "sprite_gotoXY(sprite, x, y)" or "sprite_animate()" etc.

I think a few macros might come in handy though - I made a set to convert longint-style absolute VRAM addresses into sprite register format, to account for all the bitshift/bitmasking that has to occur in order to convert a long int into a high byte or a low byte.

#define VERA_SPR_REG(ID,REG)  (0x1FC00 + 8 * (ID) + (REG))

#define SPR_ADDRLO(VA) ( (int8_t)( ((VA) >> 5) & 0xff ) )
#define SPR_ADDRHI(VA,BPP) (   (int8_t)( (((BPP)&0x01)<<7)  |  (( (VA)>>13) & 0x0F) )   )

So now in your code you can do this:
// set sprite 4 to use VRAM address 0x08000, 8bpp
vpoke(VERA_SPR_REG(4,0), SPR_ADDRLO(0x8000));
vpoke(VERA_SPR_REG(4,1), SPR_ADDRHI(0x8000,1));

Note that macros like this are best used when most of the information is known at compile time, because there are a bazillion bit shifts and bitmasks in there, and if the compiler can't simplify the expressions much, that means this will be executed as code at run-time which can get much slower than if you had stored your values in the program as natively shifted/masked already. In the example above, the compiler can completely resolve these expressions down to static values, so the underlying code is going to be the result of all of the above.



Link to comment
Share on other sites

  • 0

Yeah.  It's not any one particular thing that makes this seem painful.  But it's every little thing.

The bit-packed fields.  Well I can manage that with bitfield structures, so that solves that problem.

The VERA byte increment.  That's the fastest way, but it's just another thing to do.

Then there's the sprite updating.  I'll update the X and Y values, so that's just setting the increment and then loading the four registers -- and maybe that's OK.


I don't know, maybe it's just my old brain, and I'm used to -- well I *was* used to the C64.  Which was sooooooo limited, I won't go back. 


Link to comment
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.

Answer this question...

×   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.


  • Create New...

Important Information

Please review our Terms of Use