Quote:
Originally Posted by Bruce Abbott
In your example the data loaded/decompressed is 1000k vs 800k, which doesn't seem like like a big difference to me. After all you won't be changing levels that often, right?
But how many disks is that data spread over? Ideally there should be no more than one disk change between levels and no changes if restarting the same level.
|
I did say it was a simplified example. The game requires 2MB Chip and 1 to 2MB Fast to give a better indication of how much data is loaded. And on level transitions you may find 80% of the data changes or just 10% of it changes.
I just did a timing and level 1-2 would take 40 seconds rather than 16 seconds to load on floppy if I did not preserve files from level 1-1. I think the players prefer the 16 second version. Also bare in mind that much of that time is on decompression rather than actual disk access.
The game is on three floppies (and I went to great lengths to get it to fit - hence the compression) and there is never more than a single disk change.
Quote:
Originally Posted by Bruce Abbott
If this is fragmentation of system memory it could make the system unstable. Better to allocate the maximum amount required at startup and use it as your own private pool. If memory allocation fails you just flush and reload all, then the worst case is no worse than option 1.
|
It is not, it is a private pool that gets fragmented. It also does the flush and reload. (I both mentioned these things a few posts back). The problem is that the flush and reload is not activating correctly under this one particular circumstance - I don't expect it will be hard to fix, but it is pretty rare so I haven't rushed to doing it.