| |
Case
Registered: Aug 2002
Posts: 142 |
Depacking files from Memory
Hi, i am doing some coding and have hit a wall. I need to pack and then depack 3 pictures from memory depending on a keypress.
Can anyone help me with one ? |
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
What exactly is the question? :) |
| |
Beastifire
Account closed
Registered: Mar 2013
Posts: 40 |
Pack as in RLE (equal char) or crunch? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
LZWVL
here. PC side packer, and sourcecode for depacker. RTFM I havent used it myself. |
| |
Dano
Registered: Jul 2004
Posts: 234 |
LZWVL works just fine, used it myself.
Another alternative is TinyCrunch which in the latest version works aswell, yet is a tad faster. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Yes, TinyCrunch V1.2 should be fine for that, distribution even comes with test code that decrunches an image to $2000
NuCrunch V1.0.1 also has some sample code that decrunches an image, then an update to the image. It's a little slower, but it has a better compression ratio and lets you include multiple data segments in the stream, so the decruncher can then update a few different areas of ram for you with a single call. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I guess you can use any packer you want.
Just get crunched bytes from ram instead from a mass storage device...
Also in exomizer docs there are some examples on how decrunch directly from ram. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
In general, try the fastest (but most likely least crunchy) packer/algorithm first, then move on to increasingly crunchier (and likely ever-so-slightly slower) packers, stop when you've found the first one to produce output that *just* fits in the memory reserved for it.
That way, repeating content can be displayed randomly or in rotation with a pleasantly quick turnover.
Over at http://codebase64.org/doku.php?id=base:compression_benchmarks is a rather recent graph.
Note the 4 clusters of algorithms and the overall "the slower the crunchier" and "the faster the less crunchy" trend*.
But keep in mind, your mileage may vary, depending on content.
Edit:
* Obviously not linear, might be something like a tweaked y=1/x (x*y=1) connection. Maybe "wasted_bytes = some_constant / num_cycles" or "num_cycles * wasted_bytes = some_constant". |
| |
Erol
Registered: Jul 2003
Posts: 6 |
I can only speak from my experience.
While making Rewind (Rewind) I have extensively tested Exomizer and ByteBoozer 2.
Everything in this demo is depacked from memory and you can see the amount of content that was managed to pack in under 202 blocks.
BB2 won because depacking was faster than Exomizer and it was important for the demo pace.
So it all depends on your preferences. You need to experiment a little. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes, it very often pays off not to go for the best compression around at the cost of speed.
The only exception would be cracks which get bonus points for being the smallest version around, no matter if there's still space in memory/on the disk/image or not. :)
Exomizer being the reference for best general-purpose compression ratios on C-64, note that the graph I linked is timestamped at April 2017 at the time of writing this, which was before Exomizer 3. Exo 3 is quite a bit faster than Exo 2, yet still in the same slow camp. |
| |
Case
Registered: Aug 2002
Posts: 142 |
Hi, I should have been have given more information but it was late and i was tired.
Basically i have 3 standard bitmaps that i want to depack from memory and display one after each other on a loop.
Normally the way to do this would be to have one in each back and just flip between them, however i have some music sitting at $8000 which does not help.
I would also likt to do the depack from memory route so i can increase the number of images later on if needed.
I have tried to use ByteBoozer 2.0, but was unable to get it to depack (proberly due to my poor coding skills). If anyone has a working .exe of the packer and the depacker in kickass format i would be very grateful. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Casei have 3 standard bitmaps [...] i have some music sitting at $8000 So that's 3*10 KB for the pictures and 4-8ish KB for the tune, in a 64 KB system.
Are you sure you need to compress the pictures? |
| |
Case
Registered: Aug 2002
Posts: 142 |
Quote: Quoting Casei have 3 standard bitmaps [...] i have some music sitting at $8000 So that's 3*10 KB for the pictures and 4-8ish KB for the tune, in a 64 KB system.
Are you sure you need to compress the pictures?
not sure, my coding skills were never that great and i was trying to get a little better doing it this way. Would also like to adapt the depack from memory and maybe create another 'heartbeat' release. |
| |
Luca
Registered: Apr 2002
Posts: 178 |
I second Krill. I've used Exomizer on Plus/4 in order to depack on the fly both the bitmaps in my demopart included into Crackers' Demo 5 coopdemo: a remarkable packing ratio and easy to manage in general. If I'd been capable to use it, believe me, anybody can ;) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting CaseIf anyone has a working .exe of the packer and the depacker in kickass format i would be very grateful. Really, try to use the material that's there. If you have no working .exe, build it from source.
Likewise for the C-64 depacking part. It's a library, and as such should be assembled with the tools intended by the author. You can then easily include the binary in your project and use whatever assembler/tools you like. Translating stuff from one assembly syntax to another is a useless exercise most of the time and likely to introduce bugs. |
| |
mhindsbo
Registered: Dec 2014
Posts: 51 |
I have experimented a little with the new Exomizer. I find it quite versatile and easy to use.
It is very easy to crunch binary and prg files into a format that can be unpacked from memory.
I converted the decruncher to C64 Studio format if that is helpful to anyone.
BTW does anyone know what flag or similar you need to crunch with to use EXTRA_TABLE_ENTRY_FOR_LENGTH_THREE option? FOr some reason I couldn't find that in the documentation. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Check exo30info.txt in the newest version, and the documentation of the -P flag (near the beginning) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
For what it's worth (cue shameless plug): Krill's Loader, Repository Version 166 comes with a memory decompression call and supports various crunchers:DECOMPRESSOR = DECOMPRESSORS::TINYCRUNCH; available are NONE, BITNAX (recommended for demos), BYTEBOOZER2, DOYNAX_LZ, EXOMIZER, LEVELCRUSH, NUCRUNCH, PUCRUNCH, SUBSIZER, TINYCRUNCH (recommended for demos)
If loading isn't actually required, the code can at least serve as a how-to. |
