| |
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? |
|
... 59 posts hidden. Click here to view all posts....
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Aber Danzig.. <:) |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
go and measure ;) |
| |
HCL
Registered: Feb 2003
Posts: 728 |
:D |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
or decrunch first, load later. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote: or decrunch first, load later.
sounds like "enroll your penis, then jerk off"... oswaldb0rgar? :D |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
grab your dick and doubleclick :) |
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
In my day, the method of decrunch while loading was considered to be best since you would not have to wait after loading. The Sharks used the levelsqueezer and the GI Joe Irq loader with a desqueeze routine that operated while loading on most of their multi-load cracks. The levelsqueezer 2.0 does a fine job on reducing the size of files and the desqeezer uses less bytes than the exomizer decrunch routine. |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
It all depends on the intended flow of the demo.
If you're going for quick transitions, decrunching while
loading is a problem when loading during effects.
In this case, the decruncher will work slowly & will
most probably make the drive wait.
Best method (although lots of work) is to optimize loading
for each file, which means using the optimal interleave,
per file, according to the free cpu during its load.
With fast loaders, this method pays off big time! |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@raven: I used to think this way too, but have changed my mind after doing some testing. There is no way to choose *optimal* interleave without risking to miss a sector some time, and that will be *really* expensive with your method. ..and even though you choose a good interleave, there will be some waiting time anyways, which can be used for goodie.
Also.. in practice, there are some problems with your method. If you have file1 with optimized loading interleave 7, and file2 works best with 5, the track where file1 ends and file2 starts will be quite fragmented -> not possible to have desired interleave. Especially with many small files it's a problem. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
@hcl: what brings us to the conclusion that onefilers are teh b3tt3r demos *rofl* |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
