Quote:
Originally Posted by Muzza
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.
|
Ok, but Your game allocate memory many times. Allocation can be done only ONCE in init or via BSS hunk (better), You know size of all files necessary to be in memory. Then You allocate one big area for chip and one big area for fast/other memory, You dont free these areas before player QUIT from game. You must allocate maximum area which is necessary in same time for chip and for fast. If You will be using this method, You will be never have problem with memory fragmentation, after running game.