Sprite Palette Indices and Sprite Data (C programming)

[lghh_4]

I’ve followed the Lynx.net tutorials on basic sprites and advanced sprites (and am able to compile and show a sprite) but I’m missing the connection between the indices for the sprite pallet and how those indices match up to the values in a packed or unpacked sprite array either in the C code or in a SPRPRCK .spr file. I cannot make heads or tales out of the values in the sprite data.

 

 

How do the indices for the sprite pallet match up to the data in the sprite grid?

 

 

I've attached a picture to help illustrate my question.

 

 

 

Thank you for any help!

 

Also, Thank you Lynx.net for the amazing tutorials!

Edited April 3, 2018 by lghh_4

[lghh_4]

I changed the byte width in the hex editor and now I see the ship. So is it that within the sprite data there is a 2 byte border on the left and a 2 byte border on the right?

 

[42bs]

It is "easy" :-)

0A => size of the line

Each nibble is an "index" into the sprite color table and _not_ into the CLUT!

The color table itself contains indexes of the real color in the CLUT.

[42bs]

I changed the byte width in the hex editor and now I see the ship. So is it that within the sprite data there is a 2 byte border on the left and a 2 byte border on the right?

 

Check the docs (http://www.monlynx.de/lynx/lynx6.html#_64). It explains it

[lghh_4]

42bs,

Thank you for both the explanation and the link. I think I finally get it now!

[vince]

Beware, last nible of each line must be zero-ed. To be sure, I recommend to end each line by a 0 byte.

 

If you understand french, I made an explanation of literal/normal format of sprites : https://www.yaronet.com/topics/144007-le-format-de-sprite-normalliteral#post-1

 

If not, feel free to ask, I can "translate" it.

[lghh_4]

Hi Vince, it appears there is a 0 byte end-of-line marker already. Do you mean pad each line with a zero byte or blank pixel just before the end-of-line marker?

[vince]

Hi Vince, it appears there is a 0 byte end-of-line marker already. Do you mean pad each line with a zero byte or blank pixel just before the end-of-line marker?

No. It is good as is.

 

Remember : the line size must count itself.

[lghh_4]

Thanks Vince, I cannot read French but the website translated well in Chrome. Your post was really helpful.

Edited April 3, 2018 by lghh_4

[lghh_4]

Thanks also to Karri. Although I've never posted before until now, I've read a ton of your posts and code on this forum. I'm currently reviewing Shaken for sound.

Anyway, I'm good now with Sprites!

[42bs]

Beware, last nible of each line must be zero-ed. To be sure, I recommend to end each line by a 0 byte.

 

The sprite packer does this for you. No worry.

 

BTW: The (original) sprite-packer allows to draw sprites as ASCII file (SPS named):

 

0000A0000

020A1A020

02A111A20

0AAAAAA0

000111000

[42bs]

Hi Vince, it appears there is a 0 byte end-of-line marker already. Do you mean pad each line with a zero byte or blank pixel just before the end-of-line marker?

 

No padding needed if you use sprpck.

 

If you play around with sprites, also look at the "action" point. The sprite's x/y coordinates define it. A space ship would have in the middle of the top, a ball in the middle.

Without setting it (-axxxyyy) it is the left/upper pixel. But for your space ship I would use -a003000.

The action point is also important for tilting/stretching.

[vince]

I didn't payed enough attention, indeed.

 

Sprpck makes it easy of course