RAM & Memory Usage - what has the biggest impact?
supafly129
Member Posts: 454
From what I've read, it seems as though there are several factors that impact RAM, but are images the biggest culprit for high RAM?
I've seen some people also mention the number of actors, how big the sound files are, etc. but still not sure what's fact or fiction.
And if sounds/actors do play a role in memory usage, is there an optimal number of actors/size for sound & music files?
Comments
'Optimal' ?
Optimal would be zero for all these things !
(Except for 'music' which doesn't use up RAM), if you want to see your game run perfectly on any device, even with limited RAM, never dropping a frame, then delete everything. 
Everything (except for music) uses RAM so you need to optimise everything really, make your code as clean as possible, make your images the absolute size they need to be (no bigger) and trim your sounds down (no 8 seconds of silence at the end !).
To answer the question 'what has the biggest impact on RAM usage', that would depend on the size of the asset, a 12MB sound file will use more RAM than a 5MB image asset . . . And a 12MB image asset will use more RAM than a 5MB sound file.
The only obvious thing I can think to mention is to bear in mind the powers-of-two rule for image assets.
Adding to what @Socks said, obviously the optimal number of actors equals the minimum amount you can get away with while keeping the functionality of your game.
If you have a game that relies mostly on static actors, without any physics (e.g. a hidden item puzzle game), you can obviously pack in more actors and get away with it, compared to an action-packed platformer with flying bullets, AI-enabled enemies etc.
My personal recommendation would go something like this:
At first, build your game with a minimal amount of low-res image assets (placeholders). In some situations, this is impossible, of course, since you need precision placement of actors, but I have a solution for that later in the process.
Build your game logic in clear, understandable (for you) snippets. Name everything appropriately! This logic is quite likely to change, so you need to make absolutely sure you will understand it when you come back to it later. If you're mystified by your own game logic later on, it will make the process a lot more cumbersome! Implement all the key logic, to the extent that the game mechanics are in place and playable. You don't have to finish all the content -- for example all planned levels at this point. Try to build one that represents a more taxing variation of what will be in the final game. So, if you have different size levels, build one that is close to the maximum size you expect. Don't necessarily worry about fancy flourishes at this moment, like sparkly button animations, unless you really want to.
Now comes the first major test. You'll need two sets of images -- the low-res and full-res. Make absolutely sure your full-resolution images aren't unnecessarily large! A good rule of thumb is resolution 2x the size of the actor. Powers-of-two are important, but know what that means. If your actor is 250x250, no worries making a 500x500 texture. It will take up the same memeory as a 512x512 one, but no matter, because the other option is and actual 512x512 one, so equal footing. 520x520 texture is slicing your own throat, as it blows up to a 1024x1024 memory footprint. Just lose that tiny bit of resolution. The low-res images should be 8x smaller. If you had to use full-size images from the start to design the layout, simply make a version of each image 8x smaller in pixel dimensions. If you don't have your final images yet at this stage, take your temporary ones and blow them up to the the size your final images will be in actual pixel count.
Run the app twice on a device. Ideally ad-hoc, minimum is through the viewer. First run, replace all the images with the low-res version. Second run, use the full-res ones. Put both of them through their paces. Compare FPS, RAM etc.
This will give you a relatively good idea about what might be impacting your game.
I was once troubleshooting a project for someone and the app would lag horribly. The person started lowering the resolution of images (he was using some full-screen backgrounds), but nothing was helping. I went through the project. It was a cookie cutter style game and what was happening was that the player was getting more resources all the time and buildings were being built. All of this was managed by timers and tables. The culprit weren't the timers themselves. But inside them, so as not to lose progress on app close, the tables managing resources were being saved. Every time that is done, GS needs to write to disk. So, you had a relatively large table being saved again and again, every single split-second. But not only that! ALL the timers which managed the separate resources were doing that! In effect, the one and same table was being written to disk maybe 20-30 times (if not more, I forget the precise numbers) every second. Needless to say, after changing this, even using the original full-screen images, the lag was gone.
After these tests are done and conclusions are drawn from them, take that information, sit down and think about your app as a whole. Think about the relationships between the code snippets you created and whether they can be streamlined. Maybe you can get rid of an actor because another one is doubling its function while also doing something else. Try and slim things down, make them more elegant. Draw a schematic of the interconnected relationships if you want, that can help a lot.
Of course, you can do this sitting down and analysis before you ever create a single actor, plan everything beforehand. If you are able to do that, more power to you (though it is still good to revisit that later, since things might change as you build the app)! For most people I think this process makes more sense mid-development. Since you have a functioning prototype, you can think things through more concretely. This is why you should make your snippets clear and well named!
Rinse and repeat with the test if needed.
I tried that. An app which played one piece of music, after the loading wheel stopped.
Apple rejected it!
I even composed and played the music...
maybe that's why they rejected it. 
Lean mean code is most always the solution to lag. If you want to see integrated code in action doing fast heavy lifting with no problem see my custom collision shape animation videos.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS