| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Load first decrunch later or stream decrunch?
Work on my first attempt on an IRQ-loading demo continues. I am using Dreamload, and everything is working great.
However, some parts tend to be rather big and eat both diskspace and load time.
Obvious solution would of course be to compress the data.
As I see it, there should be two options.
1. Load entire compressed part, then decompress.
2. Load byte-by-byte and stream-decompress
At the moment I am leaning towards solution 1. To get this working, the unpacking must allow for overlapping between packed and unpacked data, since I don't have space for both obviously. But I guess a smart decompressor works 'in reverse' so to speak, so overlapping should not be a problem as long as unpacked data is larger than packed...
I have looked at Exomizer, and it seems like it does things that way, and the decompressor code is fairly compact, so it could be a way to go.
Option 2 I have not looked into as much. Dreamload does support a callback on byte-for-byte basis, so it should be possible I guess.
So, I ask all veterans in this field - how is it usually done? Any tips and general good ideas? |
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Yes, DreamLoad can handle both situations and there are also example sourcecodes for option 2 in the demo/-folder.
Exomizer is in almost all cases a good choice.
Besides this, I wonder if there is a "usual" method. It depends on taste and the actual case. I tend to load first and decrunch later, because it often happens that I don't have enough memory for the depacked part while loading and showing another effect. Then again, if you always have enough memory, it may be faster to depack on the fly, as it can partially hide waiting for a new sector. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
also, choose your cruncher wisely, exomizer gives best pack result, but is a bit slow with depacking, pucrunch depacks faster with a slightly bigger filesize.
according to krill, load+depack at the same time takes the shortest amount of time.
I'd first test exomizer to see if you still need to speed things up. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
if loading (plus depacking) speed is critical i'd also give good old levelsqueezer (or any of its variants) a try - it packs reasonably good, but can be depacked very fast on the fly. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
Quote: if loading (plus depacking) speed is critical i'd also give good old levelsqueezer (or any of its variants) a try - it packs reasonably good, but can be depacked very fast on the fly.
true, but afaik there is no crossplatform levelsqueezer... I don't think anyone would want to manually crunch files in vice each time you want to test a build... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
levelsqueezer was the first packer ever that existed on pc =) its in the old taboo-assembler (6502tass or whatever it was called) package if i recall correctly. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
in 64tass? got a link? the sources I have are from 1.45b, and they don't compile... also, there's no levelsqueezer sources in there... |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
Partly out of old habit I use level crusher and decrunch while loading. Levelcrusher for dos is really fast and I think Krills loader in combination with lc has given me the best results when it comes to speed. Levelcrusher for dos is included in the bonus directory of tass here 6502TASS V1.31 , along with a depack routine. You could ask Krill for his loader sourcecodes which include a lc depacker routine.
I've also used levelcrusher together with dreamload, and it didnt take much code to be able to decrunch while loading, load and decrunch later and load unpacked. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i vaguely remember the source for that cruncher beeing available aswell.... mmmmh *shrug* |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
what ninja said. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Well, you won't come around experimenting a bit and develop a feeling for an apropriate solution.
Depacking on the fly can be quite faster, if you know what you are doing. If not, there is hardly a difference.
Exomizer can be slower when depacking, but maybe it pays off as you might have to transfer one or a couple of sectors less? And what if you rewrite the decompressor just a bit to speed it up (replacing JSR getbit with a macro already helps)?
So many options and we haven't talked about interleave yet ;)
@Shadow: If you don't need maximum speed, take an easily understandable approach. Doing the first trackmo is usually complicated enough. |
... 59 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
