For reasons that I'm don't feel like going into at the moment, a while back I made one of those simulators that simulates spread of a(n) epidemic/computer virus/forest fire/whatever.
All right. So I wanted it to go through a bunch of simulations, testing the affects of incrementing the various parameters, and save the results. No problem, except for the save files were ~ 5 billion kb per iteration (x 500 iterations per simulation).
I tried BSAVES (the area to be saved is 100x100 pixels). I tried TYPEs. I realized that there were only four colors the pixels could be = 2 bits/pixel = 4 pixels/byte, but that's still 2500 bytes/iteration. I tried this complex thing where bits 1 and 2 indicated the color, bit 3 indicated whether or not bits 4-11 indicated how many times the color repeated. The first dozen iterations were good (~100 bytes each), the rest were not, and it slowed down the program like crazy.
Strictly speaking, all this work isn't absolutely necessary, but it's become a challange in and of itself. I don't like running from challanges.
...
</rambling>
...
I need help.
It depends on how the image changes from an iteration to another. The approach is similar (to a limit) to MPEG-like compression.
You try to save just the pixels that have changed. If the size of the saved data is bigger than the whole image, you save the image RLE-encoded.
This is the first time I've done something like this, and I'm not familiar with MPEG (or MPEG-like) compression. Could you give me a link to somewhere where I could learn more?
No, no, I only mentioned MPEG 'cause it is similar, but in fact it has nothing to do
I only wrote it from the top of my head.
What I mean: Imagine that from iteration 2 to iteration 3 only three pixels change. Then you save "x, y, colour" of each changed pixels, that makes frame 3 = 9 bytes. THe problem comes if more than 1/3 of the pixels change. That way, saving the position of the changed pixels would make the data take more memory than storing the whole image. In such cases, you store the whole image using RLE or another compression algo.
Duh.
I seem to have a knack for overcomplicating things.... I think whether or not 1/3 + of the pixels change will vary with the initial parameters, though most of the time there will definitely be less.
But thanks. I'll give it a try.
So, that's only 1250KB, only one meg! Do you really need to compress it??
If you have very few changes per iteration, one thing you could do is have an initial starting map and then list the changes. Structure:
Initial map.
amount of changes for iteration 1.
[x loc, y loc, change-to-what?] list
amount of changes for iteration 2.
[x loc, y loc, change-to-what?] list
etc.
EDIT: Oh, that's what Na_th_an was suggesting earlier. . . You'll need a lot less than 1/3rd of them to change under this scheme, though. Each x/y loc/change-to-what combo takes 16 bits..
16 bits? You need at least 7 bits for X, 7 bits for Y and 8 for colour (assuming you are in SCREEN 13, 256 colours, of course). As QB is like a turtle with bitwise operation, the easy way is to use 8, 8 and 8, thus 3 bytes.
As I mentioned earlier, there are only four colors possible in the area in question (so two bits / pixel = 4 pixels / byte).
So if I used bits instead of whole bytes:
Assume 1/7 of the 10,000 pixels change on average ~ 1429 pixels
Now 2 bits for the color plus it would take 14 bits for the (x,y) coords = 16 bits/pixel * 1429 pixels = 22864 bits = 2858 bytes per iteration.
Whereas if I stuck to recording every pixel every iteration.... 10,000 pixels / 4 pixels per byte = 2500 bytes / iteration - actually an improvement, saving on average 358 bytes / iteration. (I love nitpicking).
Of course, if I chose not to sacrfiice speed for space, there'd be 1429 pixels changing * 3 bytes = 4476 bytes / iteration.
.....
Anyway, I guess this isn't the most serious problem facing the world today, and I could used any one of the above solutions (plus winrar) and still get tolerable file size. (Please remember this won't be limited to 1 simulation!).
Thanks for your help, guys!
But still.... would there be a better way?
::EDIT::
So aga was right about the 16 bits thing, but I'm assuming that's only because I didn't clarify enough to na_th_an that there'd only be 4 colors. Sorry 'bout that.
Aw, I misread your original post, sorry. Then my sollution wouldn't work in most cases, considering you have 1/7 of average changes.
With just 4 colours a LZW compression algorithm would work neat. I can't give you any directions on this as I've never researched, but from what I know you'll get a nice compression.
As far as I know, LZW finds patterns. It keeps a dictionary. If it finds a pattern in the image that is already in the dictionary, it places a direct link to the dictionary. If not, it updates the dictionary.
I'm sure you can google for neat pseudocode.