| 23 Mar 2009 04:47:13 pm by Galandros |
|
|
| bananaman wrote: |
Yes, the decompressing routine is 250 bytes.
If the 32x32 map has good patterns in it, then it may be compressed down to 250 bytes. I am currently trying to create a modified version of arithmetic coding and we are getting about 70% compression. There are a few bugs to work out, and I believe that I will still have to lower the precision to have the routine fit on the calculator. |
Dwedit also made an apack decompressor many time ago.
See this topic of MC forum: http://www.junemann.nl/maxcoderz/viewtopic.php?f=1&t=100
And it was 250 bytes too...
PS: I hope I am not making an huge mistake about this... |
| 23 Mar 2009 04:52:21 pm by bananaman |
|
|
| The Arithmetic encoding will not work well on the calculator. Since the calculator is restricted to using 16 bit registers and there are not very many of them. I was unable to make Arithmetic encoding work with any suitable amount of compression. I was getting 70% compression with Java, but I had to lower the precision to get a decompression routine to work on the calculator. This caused the compression percentages to drop considerably. |
| 24 Mar 2009 12:54:50 pm by Galandros |
|
|
| bananaman wrote: |
| The Arithmetic encoding will not work well on the calculator. Since the calculator is restricted to using 16 bit registers and there are not very many of them. I was unable to make Arithmetic encoding work with any suitable amount of compression. I was getting 70% compression with Java, but I had to lower the precision to get a decompression routine to work on the calculator. This caused the compression percentages to drop considerably. |
Why did you not posted us with that news before? I still got and answer for the dwedit work... :P
That is not good, though. Still it compresses enough to put the levels in the calculator? And there is other option?
Repeating tr1pea in MC forum or RS iirc: apack has average better results than pucrunch. But in The Verdant forest pucrunch beat apack... |
