Need Help with Optimization for Android

Hi guys

I have recently finished a game for Android that runs really well on many of the Android devices - it runs great on a Samsung S3. It has come to my attention that some of the older devices, such as some of the HTC, don't run the game as well. I'm running it at 32,000 colours and using the PMO object, so there are no fast loops, and I've tried to optimize my code with active/inactive groups as much as possible. I have 2 requests:

Can you please explain to me what things are happening that are using my memory resources and might be causing a slow down?

Can you tell me how I could optimize it further?

The more I understand what's going on, the better I will be at optimizing my future games. Also, not included in the file are the two music tracks, which are both very large WAV files that account for 99% of the games 30MB file size. Could that be adding to the slow down?
Thanks in advance for your help.


Simflare

I can't look at your game right now, but here's a few thoughts.

- Your Galaxy S3 has 1gb of memory, how much do these lesser devices have? Anything less than 512 and there's pretty much no hope for them with the Android exporter. A device with 512mb of memory has to run the android os, the fusion runtime and your game on top of that, so it might be pretty slow no matter what.

- There is a new build for the Android exporter coming out (who knows when.. no one will tell me!) that is apparently much faster than the current build, that could help.

- is there a reason why you're using wavs? are mp3's not compatible? I haven't added music to any of my projects yet >_< It's easy to save a .wav as a .mp3 using the free program Audacity.

- I believe you can limit compatibility of your game so that older devices can't download it? It's not ideal.. but an option.

- I'd have to look at your file to see if there's anything I'd recommend changing.

Thanks Dave for your thorough response. I had wondered about limiting older devices - that's a plausible thought, but I'd prefer to leave it as a last resort. I'm also not sure how to do that. I can see you can choose the minimum Android version, but I can't see any other area's for limitations.

A new Android Exporter would certainly help.

MP3's are compatible - would it make a difference to the projects speed, the size of the file?
The problem with MP3's is that you have to pay royalty / license fees on them. I have been using WAV files to avoid such issues. (that leads to another issue though, because apparently you can't upload files over 50mb to google playstore)

Let me know if you can recommend any other optimizations from the file.

Cheers

Simflare in regards to the very large .WAV file, OGG's are the best alternative. AFAIK there's no royatlys or anything, they work great with fusion and can be exported to using Audacity. I export all my MP3 files to OGG when i use them in Fusion and on Android.

I just got a little nervous as I was reading about the cost of mp3 licensing on other pages, then I searched for indie alternatives and the recommendation was ogg.. then I was like.. damn, I hope oggs are supported in the Android runtime.. so I searched the forum, and ended up back here haha that's good to know .oggs are supported, macca!

I'd suspect that using oggs could take some load off the memory.. I believe a wav has to be loaded into memory at the start, so a 2mb ogg would in theory be preferable to a 30mb wav..

Okay, so there's some stuff you could change for the better..

- you've kinda ignored the powers of 2 lesson xD the city scape image for example is 1600 pixels long.. that would be treated as 144x 2048 pixels long.. it'd be MUCH better if you could get it down to 1024x128 or maybe even 512x128.

- you could destroy the splat cat logo with the alpha channel when it's not needed (I'm not sure if this would speed it up or not as you do make it invisible)

- you have a number of timer events related to creating things.. which is bad. the timer gets thrown off when the frame rate drops.. so suppose there is a slight lag at first, this will compound over time and create more and more stars etc. as frames will be skipped, you might end up with hundreds of stars on screen at once if it got slow enough. It's like a positive feedback loop.. if you tested on a slow device you'd be horrified. A little lag means an extra star gets created before you'd expect, which cause a little more lag, which causes more objects to be created 'before their time' and on it goes.

- the giant active on the bottom of the screen (to detect player falling I assume) is completely unnecessary, instead of checking for a collision just check for the y position of the cat or the cats detector. (so delete that active and instead have Y position of cat > 580 - lose!)

- any time you do need an invisible object like that, you're better of making it a 1x1 pixel object and then scaling it at runtime, that 998x32 object is now 1024x32.. all that extra texture memory adds up.

- you only need to test once for the player collisions, and collide works just as well as overlapping (overlapping costs more cpu) so I'd get rid of the collisions group entirely and just have the one event "test for overlap + cat collides with traps" since all the platforms share a qualifier it should really only be 1 event.

- use fine detection is left on for some objects that don't need it, may as well turn it off.

- it'd be better to load the music tracks on a frame before your main gameplay frame, this way it will only keep 1 song in memory and each time you end the level you can clear the memory by jumping to a blank frame and then load the other track.

- instead of using "detector is overlapping medium platform" use "detector collides with medium platform) overlaps are bad.

so yeah.. don't use the timer! (especially for this kind of game where the core game-play is dependant on making sure nothing goes out of sync) make sure your graphics waste NO space! have a frame jump to "flush the memory" (this is at least true for the iOS exporter so I suppose it would be for Android too) try not to use "overlapping" collision checks wherever possible.

see how that goes!

Thanks Dave!

I get most of what you've said. I don't know that I can really do anything about the buildings, I can't really change their size even though I realise they disobey powers of 2, because it would change the gameplay too much.

I don't fully understand what you mean about the music. Do you mean, on a blank frame, you would have something like "start of frame > play song"?
It sounds like an interesting suggestion, but it also sounds like you wouldn't be able to change songs during a game. Part of the reason for the way I've set it up is so that songs can change mid-gameplay, giving you a variety of moods during a long game.

How could I create the stars at separate intervals without a timer? Would you suggest I create a custom timer with a variable that gets 1 added to it 60 per second?

Thanks for all of your tips. Some of them are really good! I slapped my forehead when you mentioned about the cat dropping off the bottom of the screen - yep, shoulda done that. I will implement these as soon as I can!
I didn't realise overlapping took up so much extra memory. Thanks for the tip!

Just tried out OGG files with Audacity - works perfectly! My file went from 31mb to 4.7mb! Brilliant!

I have implemented your suggested changes Dave (except for the music - still need you to clarify about the empty frames). When you said power of 2, were you referring to the city in the background, or the buildings you jump on? Possibly I could change the city in the background to be half the size, it's just a bit of extra programming to get it to loop. It was easier to loop it at it's current length.

Cheers to both of you! Now I will see if the performance improves! The smaller file size should help a lot :D I'll let you know soon.

if you want the music to change during gameplay then yeah, you have to keep it the way you have it (I'm not even certain that it will make a speed difference, it just seems logical to me that it could)

yeah I meant the city background, that could definitely be cut down in size and it wouldn't be too noticeable seeing as the player is focused on not dieing rather than looking at background details.

The built in timer I've had trouble with in the past, the way I understand it is that if your game is going at say, 60 frames per second, if there is a bit of lag, the timer can skip a beat and mess things up. If you instead add a value every frame (like, "always" add 1 to value A) and then when value A=60 add to value B (this is 1 second, 60 frames.) you can use value B as your timer. Apparently even if the app starts to lag, it's still keeping track of each frame, nothing should get missed, everything stays in sync. If you have some timer based actions and some frame based actions things can get especially messy.

Ah ok thanks for those clarifications Dave.

Yeah I thought that if you "always add 1 to Value A", that it would go up 60 every second at 60 fps, but wasn't 100% sure. That's a very helpful clarification! Thank you.

Also, do you think it might be a wise decision to use machine independent speed in this particular scenario? From what I understand it would help it run better on slower devices, but I also have the impression it can make the game skip frames, and therefore might still ruin gameplay. Your thoughts?