Ow .. now it makes sense. Again, I feel a bit stupid. Thanks for clearing this up. It works now, I was going by the example and didn't realise there was another optional parameter.
As for the extra functions, that is a good question.
When I downloaded this, I went by the examples to figure out what I should do.
From this perspective, I would say: adjust the example to use the "unpackedSize" parameter. Since this is the 'safe' method, I would consider it the 'official' method. Leaving the parameter out is optional. It is then up to the user to find a way to store the original size of the data.
Maybe, instead of estimating, you could define the temp. bank size with the maximum size that is available.
The CompressBank and UncompressBank functions are a good solution. Since they can co-exist next to the original functions, they would harm nobody. For me, I see no use in altering the compressed data, so it wouldn't matter if the size is stored there as well. For some reason I would say to store the 'size' at the start of the bank, but I don't know why. Maybe it is because I've seen that so often with other structures.
It works too good, this lib. I wanted to see if it is possible to make a single-file installer using the bank compression functions.
So I've converted all the files into banks, compressed them, converted them into Data statements and then with another program I uncompressed them and wrote them back to disk.
(To be able to use such a long source, I used "Include" to include it and didn't try to open it with the IDE.)
I've stored and restored 7.56 MB of files this way. It took BB about 5 minutes to compile, but it works! Amazing, don't you think ? Well, I've never done anything like it ..
So, actually, I didn't encounter any problems at all. It just works, and it is very good.
As for the extra functions, that is a good question.
When I downloaded this, I went by the examples to figure out what I should do.
From this perspective, I would say: adjust the example to use the "unpackedSize" parameter. Since this is the 'safe' method, I would consider it the 'official' method. Leaving the parameter out is optional. It is then up to the user to find a way to store the original size of the data.
Maybe, instead of estimating, you could define the temp. bank size with the maximum size that is available.
The CompressBank and UncompressBank functions are a good solution. Since they can co-exist next to the original functions, they would harm nobody. For me, I see no use in altering the compressed data, so it wouldn't matter if the size is stored there as well. For some reason I would say to store the 'size' at the start of the bank, but I don't know why. Maybe it is because I've seen that so often with other structures.
It works too good, this lib. I wanted to see if it is possible to make a single-file installer using the bank compression functions.
So I've converted all the files into banks, compressed them, converted them into Data statements and then with another program I uncompressed them and wrote them back to disk.
(To be able to use such a long source, I used "Include" to include it and didn't try to open it with the IDE.)
I've stored and restored 7.56 MB of files this way. It took BB about 5 minutes to compile, but it works! Amazing, don't you think ? Well, I've never done anything like it ..
So, actually, I didn't encounter any problems at all. It just works, and it is very good.