This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's
Your Projects subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.
Sonic =>
Your Projects
| Author |
Message |
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
 Posted: 23 Mar 2009 04:47:13 pm Post subject: |
|
|
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... |
|
| Back to top |
|
|
bananaman
Indestructible
Calc Guru
Joined: 12 Sep 2005
Posts: 1124
|
| Posted: 23 Mar 2009 04:52:21 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 24 Mar 2009 12:54:50 pm Post subject: |
|
|
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... |
|
| Back to top |
|
|
|
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
