I implemented most of the sprite support on the weekend, just didn't test it (except for the single pixel output, testing the RAM tile allocator). It is up in the repo including the documentations.D3thAdd3r wrote: ↑Mon May 28, 2018 1:39 amSeems like 24 byte sprites is already really efficient and I doubt anyone's game hangs in the balance without some 20 bytes variant (which I don't understand actually). With the standard sprite stuff implemented, this is yet another crazy good mode to be used for games that fit it's specs. No developer can come to Uzebox and say Jubatian didn't offer them enough video angles for their particular game
The 20 byte sprites would have been nice if you wanted to have them in RAM (for example some boss image or something alike loaded from SD in a larger game), by using a converter, it wouldn't have been necessary to actually understand the format. It just really didn't get along well with the need of line by line access necessary for blitting onto the RAM tiles. By the way the absolute theoretical minimum is 19 bytes (log2(5^64) is just below 149, bits, so 19 bytes, 5 is the count of possible pixel values: 4 colors + 1 transparency, 64 is the tile size in pixels).