Memory Management

[Havie]

Prompted by my Flappy Bird game not running on an unexpanded A500, I thought a discussion on saving memory (especially with graphics) might be useful. So please discuss/post tips etc.

[Havie]

I'll start by bringing up Daedulus' comment in another thread. He suggested that by loading lots of graphic files individually that this can lead to memory fragmentation. Therefore would it be better to load in one file and grab images from this? Do others do this or have other ways of getting graphics into games?

[haps]

Does not fragmenting threads prove a point?

[Daedalus]

To be fair, the discussion wasn't really on topic in the other thread, which was about Amiga Addict magazine so it makes sense to create one here.

But anyway, loading or creating a graphical object will allocate an area of chip RAM to store the graphical data. That area will be located at the first free area that's large enough. The next object loaded or created will do the same, which means it will often appear next to the previous object in memory. Now, this is fine until you don't need some of them any more. You can free the objects you don't need and that will free up their RAM, but it doesn't move the location of any later objects which weren't freed, so what happens is that you have a small bubble of free RAM surrounded by used RAM. When you then need to create a larger object, it won't fit into any of those small empty bubbles, even if it's smaller than the amount of RAM they collectively take up.

In this respect, whether you grab the shapes from a single file or load them individually doesn't make much difference - the problem is that if you free some of them up later it's difficult to reuse the RAM they took up. One possible approach is to make sure the objects that will be freed up are all the last objects to be created. That way, when you free them up, their space is all side-by-side and therefore is a single, large block when it's freed. And if nothing else is allocated in the meantime, that large block will be next to the rest of the free chip RAM, meaning it can be used for much larger objects.

In your particular example, this is complicated by creating sprite objects from the shapes. The first thing to do though is to load all the shapes first, then create your sprites. This way, at least the shape objects will be side-by-side in RAM, instead of being Shape-Sprite-Shape-Sprite... So when you free the shapes, at least you'll have a single free block the size of all the shapes, instead of a single shape-sized block in between each sprite and the next.

[Havie]

Originally Posted by Daedalus

To be fair, the discussion wasn't really on topic in the other thread, which was about Amiga Addict magazine so it makes sense to create one here.

But anyway, loading or creating a graphical object will allocate an area of chip RAM to store the graphical data. That area will be located at the first free area that's large enough. The next object loaded or created will do the same, which means it will often appear next to the previous object in memory. Now, this is fine until you don't need some of them any more. You can free the objects you don't need and that will free up their RAM, but it doesn't move the location of any later objects which weren't freed, so what happens is that you have a small bubble of free RAM surrounded by used RAM. When you then need to create a larger object, it won't fit into any of those small empty bubbles, even if it's smaller than the amount of RAM they collectively take up.

In this respect, whether you grab the shapes from a single file or load them individually doesn't make much difference - the problem is that if you free some of them up later it's difficult to reuse the RAM they took up. One possible approach is to make sure the objects that will be freed up are all the last objects to be created. That way, when you free them up, their space is all side-by-side and therefore is a single, large block when it's freed. And if nothing else is allocated in the meantime, that large block will be next to the rest of the free chip RAM, meaning it can be used for much larger objects.

In your particular example, this is complicated by creating sprite objects from the shapes. The first thing to do though is to load all the shapes first, then create your sprites. This way, at least the shape objects will be side-by-side in RAM, instead of being Shape-Sprite-Shape-Sprite... So when you free the shapes, at least you'll have a single free block the size of all the shapes, instead of a single shape-sized block in between each sprite and the next.

This is the sort of thing I thought would be helpful. So basically I need to rearrange the loading of graphics so that the sprite shapes are last so when I copy the sprites into shapes, I can then free up the shape (chip ram) before setting up the screens.

[Havie]

Is there any way of getting screen chip ram back? If so, as I open a dual playfield screen and third/fourth screens (for the start/game over) at the end - I could close the dual playfield screen before opening the game over? Is this sort of thing possible?

Also, I load some quite large files into shapes at the beginning of the game so there is no loading once the game is running but I could load some of these files when needed and then free up afterwards. Will have a little play with this as could be quite useful to get my head round it and might help others with their memory management. I think part of the problem is that I am still thinking like a pc programmer with basically 'unlimited' ram!

[Daedalus]

The screens themselves in this context don't take up much RAM. They just point to a bitmap in memory and display that as required, and it's the bitmap that takes up all the RAM. You can free bitmaps, but be careful of doing so if they're in use or going to be in use again - blitting to a non-existent bitmap is bad news.