Quote:
Originally Posted by Don_Adan
Allocation and deallocation memory via exe calls is never good solution for programs which calls these many times. Because no memory available problem will be always occured after some calls. For me the only good solution for allocating memory is using 1 BSS and 1 BSS_C hunk, or 1 call for alloc all necessary chip memory area and 1 call to alloc all necessary fast/other memory in init routine. Your program can handle allocated memory. Of course You must alloc the biggest chip and fast area used by game in same time. I prefer to use BSS version, because is shortest, and You can see "not enough memory" information at begining, if not enough memory is available.
|
That is what the game does. It allocates a single block of Chip and Fast and then manages it internally. It doesn't solve fragmentation though, in fact it makes it worse in cases like this where the system has plenty of additional free RAM. WHDLoad only allows a single block to be allocated and it happens before the game code even starts running.
Consider that when the player transitions from level A to B, some game assets are required in both (so are preserved in RAM), other game assets are no longer needed (so are free'd), and then new assets are allocated.
Then when you go from level B to C, the same again, but different. Even the main display gets reallocated, for different colour/fetch modes.
Having every level release all allocations, and then the next level re-load/re-create them would solve it, but at the expense of loading times.
My less than ideal compromise was to check the largest free block size during each loading phase, and once it gets to a critical low point, do complete release and re-load of that level. It only really happens once you've done multiple play-through's of the game, and it seems I didn't tune it perfectly - although it is the first report of it in seven months of release so not all that common.