Sprite data format

[ervin]

Hi everyone.

Originally, my large Savage sprite for Chunky Pixel Collision was just defined as a series of values.
So, as it is a 64x64 sprite, it took 4K, which is completely unacceptable.

I came up with a different way of representing the sprite, which also required a complete rewrite of the sprite code.
It was just a list of colours, with the number of pixels to be painted each colour.

ie. reps1,colour1,reps2,colour2,...,repsN,colourN.

Still, Savage takes up almost 1.5K this way, which is still too much.

Does anyone have any amazingly clever ways to store sprite data, that can be used in realtime?
I need to think of another way to represent the data, that won't rob my game of the memory it needs.
I've got no issues at all with another sprite code rewrite, so let the crazy ideas flow! 

Thanks for any help.

[arnoldemu]

You could add a code for end of line if you don't have this already?
then you don't need to process transparent pixels on the right and you also have less data?

also for the left side you could do the same?

Ok, since each colour is one of 16 possibilities, store each colour in a nibble. You could also store the count in a nibble too allowing single runs of up to 16 pixels (0=16, 1-15 = their value)?

If you add the end of line code, you'd have less run, e.g. 0 = end of line, 1-15 = their value.

some ideas that could work?

[ervin]

Thanks for the quick reply!

I do indeed have beginning-of-line and end-of-line codes.
They help a lot, and speed up the sprite processing a bit as well.
Transparent pixels on the inside are also skipped by adding the required value to the relevant memory address.

The nibble idea though... I like it.
I don't know how I'll process it yet, but no doubt it involves ANDs or ORs or somesuch.
I'll give it a go! 

Thanks again.

[redbox]

I don't know how I'll process it yet, but no doubt it involves ANDs or ORs or somesuch.

Or you can use shifting (SLA, SRL, RRC, etc.) and it's worth remembering that the carry flag can be used with these too (for conditional jumps like JR C,address etc).

[ervin]

Ah, I see.
Cool - thanks for that.

The more information, the better!

[redbox]

I recently came up with the same idea as arnoldemu for compacting graphical data.

However, this idea does depend on the next pixel to print being less than 16 pixels away.  For example, if you store the byte and colour information as two nibbles in one byte, it could be

Code Select Expand


128 64 32 16 8 4 2 1
  1  1  0 1  1 0 1 1


Firstly, AND the above with %00001111 and this would leave you with:

Code Select Expand


128 64 32 16 8 4 2 1
  0  0  0 0  1 0 1 1



Which equals 8+2+1 = 11, and this can be your PEN colour.  Then, rotate right 4 times with RRA and you end up with:

Code Select Expand


128 64 32 16 8 4 2 1
  0  0  0 0  1 1 0 1


Which equals 8+4+1 = 13, and this could be the number of pixels/bytes to increase for the next pixel to display.

Sorry if this sucking eggs for you, but thought I would explain it for everyone....!  And there are ways you could optimise this further 

[ervin]

I was thinking along similar lines, but having it explained like that is very helpful.
Thanks man.

[Axelay]

Well the good ideas appear to have been covered, but hey, you asked for crazy 


If using a nibble type method, could a bit be set aside for indicating 'patterns' that you look up, so that commonly occurring groups of different coloured pixels that might take 3-4 bytes only need take one, though you are then limited to a maximum of 8 pixels of one colour in a row rather than 16, which might cause more repeats and eat as much memory as it might save.  I'm sure this would end up being slower too.


Another idea, I'm not sure how you would be translating the ink 0-15 indicator to screen data information (I mean because it isnt a straight nibble), but if whatever you're doing required a lookup table you could say, instead of having colour info stored in a 16 byte table at &8000-&800f, store them at &8000, &8010, &8020 and so on, taking a whole 256 byte 'page', but it means you could take the data byte AND &f for the pixel count, and only need to AND &f0 to get the position in the lookup table, saving on the need for any shifts.

[ervin]

The more crazy, the better!
Some very interesting ideas in there!
Thanks for all of that.

I'll give them a thinking through and see if I can use any of them.
Top stuff.