Compression

[ghost]

A new enhancement idea:

Something like Exomizer (or similar) integrated in CPCTelera library and build system would be a great feature.

Thank you.

[lronaldo]

This feature was already in our internal todo list. I think is a greatly important feature. However, it will require time to find a great way of including the feature into the build system, to make it easy and comfortable to use.

It will also be interesting to have a live compressor, to be able to compress things live (It could be useful for procedurally generated content, for instance)

[deringenieur71]

I have an idea -> you put exomize into tool_path and spend a makro/skript. Like here 👍
http://www.cpcwiki.eu/forum/programming/(cpctelera)bit-arrays/msg122514/#msg122514

[lronaldo]

Thank you, @deringenieur71. We are thinking on similar ideas to include exomizer and other compression utilities. Our main concerns are being respectful with original authors and their licences and designing a good way to automate the proccess of having compressed data.

Hope to have this future well integrated soon 😄

[Arnaud6128]

The LZ48 compressor was release and it works very well with SDCC/CPCTelera. The Cruncher/Decruncher C Code is provided. Maybe we can add it to CPCTelera and include other compressors in near futur.
http://www.cpcwiki.eu/forum/programming/lz48-cruncherdecruncher/

[lronaldo]

Thank you, @Arnaud6128. I've already considered LZ48/49 compressor. I think it is really interesting and I've been following the development since its inception. I've already have a look at your adaptation. Thank you very much for all the nice work you are doing :). I hope to be ready to start again in 8 to 10 days and add all these many great things to CPCtelera.

[Arnaud6128]

i don't know if it's possible, but a very useful feature could be to directly decompress data into video without having to copy into temporary buffer.

[lronaldo]

@Arnaud6128 You can do that already. You only have to decompress to Video RAM. Many games already do that for backgrounds and presentation screens. Are you referring to a different way of decompressing?

[Arnaud6128]

I was refering about sprites for decompression and blitting in the same operation.
For sprite i had to decompress it in buffer and call cpct_drawSprite to display the buffer and i was thinking about a function like cpct_drawCompressedSprite.

[lronaldo]

@Arnaud6128 I have thought of similar ideas time ago, but I concluded that they are rarely of use. Individual sprites are normally to small to be compressed individually. Moreover, decompressing and blitting simultaneously would be many times slower than normal blitting. All in all, having general compressed sprites does not seem a good idea. There may be some special cases in which that's actually useful (very big sprites that do not need to be drawn fast, for instance), but then its priority to be implemented becomes lower.

The only interesting way would be finding some special compressing format that doesn't hurt overall blitting performance: something specially designed for sprites. In that case, and having good performance tests, it could be really beneficial. I think that requires a good deal of thinking, trying and redesigning, or a bright idea. It's a great challenge to invest some time researching :)

[AugustoRuiz]

Maybe implementing RLE sprites would be nice... You would save some space, and no masks would be needed too. Encoding RLE would be like so: OPCODE (1 byte), LENGTH (1 byte), [DATA (LENGTH bytes)]. OPCODE = 0x0 -> Transparent pixels (LENGTH bytes), in this case, it would be 0x00 0xLL, no data bytes required. OPCODE = 0x1 -> Semi-transparent pixels (LENGTH bytes). In this case you would have 0x01 0xLL 0xD0, 0xD1 .. 0xDL-1 OPCODE = 0x2 -> Opaque pixels (LENGTH bytes). In this case you would have 0x02 0xLL 0xD0, 0xD1 .. 0xDL-1

…

On Fri, Dec 16, 2016 at 6:15 PM, Francisco Gallego ***@***.*** > wrote: @Arnaud6128 <https://github.com/Arnaud6128> I have thought of similar ideas time ago, but I concluded that they are rarely of use. Individual sprites are normally to small to be compressed individually. Moreover, decompressing and blitting simultaneously would be many times slower than normal blitting. All in all, having general compressed sprites does not seem a good idea. There may be some special cases in which that's actually useful (very big sprites that do not need to be drawn fast, for instance), but then its priority to be implemented becomes lower. The only interesting way would be finding some special compressing format that doesn't hurt overall blitting performance: something specially designed for sprites. In that case, and having good performance tests, it could be really beneficial. I think that requires a good deal of thinking, trying and redesigning, or a bright idea. It's a great challenge to invest some time researching :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANE5qEMK9OjQH-Pl3-ozyq0ZZzkBAsGBks5rIscwgaJpZM4HARoe> .

[AugustoRuiz]

For semi-transparent pixels we might have two opcodes, one for left pixel transparency and another one for right pixel transparency. In this case, and taking into account that usually you don't have many consecutive semi-transparent pixels, we could omit the LENGTH byte and assume there is only one byte. So the coding would be: OPCODE = 0x00 -> transparent pixels (LENGTH bytes) OPCODE = 0x01 -> left pixel transparent (no LENGTH byte), 0xDD (this byte would always be masked against the same mask, the one that leaves the left pixel transparent). OPCODE = 0x02 -> right pixel transparent (no LENGTH byte), 0xDD (this byte would always be masked against the same mask, the one that leaves the right pixel transparent). OPCODE = 0x03 -> opaque pixels (LENGTH bytes). On Fri, Dec 16, 2016 at 6:47 PM, Augusto Ruiz <augusto.ruiz@gmail.com> wrote:

…

Maybe implementing RLE sprites would be nice... You would save some space, and no masks would be needed too. Encoding RLE would be like so: OPCODE (1 byte), LENGTH (1 byte), [DATA (LENGTH bytes)]. OPCODE = 0x0 -> Transparent pixels (LENGTH bytes), in this case, it would be 0x00 0xLL, no data bytes required. OPCODE = 0x1 -> Semi-transparent pixels (LENGTH bytes). In this case you would have 0x01 0xLL 0xD0, 0xD1 .. 0xDL-1 OPCODE = 0x2 -> Opaque pixels (LENGTH bytes). In this case you would have 0x02 0xLL 0xD0, 0xD1 .. 0xDL-1 On Fri, Dec 16, 2016 at 6:15 PM, Francisco Gallego < ***@***.***> wrote: > @Arnaud6128 <https://github.com/Arnaud6128> I have thought of similar > ideas time ago, but I concluded that they are rarely of use. Individual > sprites are normally to small to be compressed individually. Moreover, > decompressing and blitting simultaneously would be many times slower than > normal blitting. All in all, having general compressed sprites does not > seem a good idea. There may be some special cases in which that's actually > useful (very big sprites that do not need to be drawn fast, for instance), > but then its priority to be implemented becomes lower. > > The only interesting way would be finding some special compressing format > that doesn't hurt overall blitting performance: something specially > designed for sprites. In that case, and having good performance tests, it > could be really beneficial. I think that requires a good deal of thinking, > trying and redesigning, or a bright idea. It's a great challenge to invest > some time researching :) > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#23 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ANE5qEMK9OjQH-Pl3-ozyq0ZZzkBAsGBks5rIscwgaJpZM4HARoe> > . >

[lronaldo]

Current development branch has compression integrated:

• ZX7B compressor integrated,(thanks to @antoniovillena)
• cpct_pack front-end command for easy usage
• Makefile macros ADD2PACK and PACKZX7B up and running. They let the user add selected files to a packing group and then generate two files (.c .h) with the compressed data array for all added files. It also generates constants for easily using compressed and uncompressed data.
• cpct_zx7b_decrunch_s function to decompress previously compressed data.

Everything is automated and ready to use.

I will continue adding more versions of ZX7B and also Exomizer, but I consider this issue solved by now.