game-editor.com

Hey friends! I have been working a lot on a shmup for the past few weeks. I have tested it on several systems (even a 500mhz celeron) and have had great results so I figured it would be smooth sailing on the iPhone. Sadly I was very wrong =( It ran anywhere from 2-5 fps when several shots were on the screen and several things behaved totally different on the ip then any other test system.

After looking closely I have found a few problems, a few of them were coding errors like a misspelled animation name and a few of them were just bizarre and something would not happen when it was supposed to happen. Anyhoo! I worked through most of it and cleaned up some stuff. But I was just wondering is there some general "do nots" for iPhone's as far as coding goes? It seems to behave a bit different then the windows compiles.

After tweaking many things, omitting sounds and cutting down drastically on animation frames I was able to get it to run much smoother. I was wondering if there were any good guidelines to follow to make the ip more optimized. I followed some posted by krenessus (sorry for sp) which said to avoid infinite actors, to write as little code as possible and to avoid having too many regions and transparent actors. Is there anything else I should know? Would using a lower bitrate picture improve performance? Would using one type of picture over the other improve performance? I'd appreciate any help!

Smaller images are better, minimize the amount of transparency, if you want fading, use an animation. The amount of code isn't a problem, krenisis wasn't a very good coder though, so maybe it did present some problems for him (though most of his games had no more than 5 lines in a script). Optimizing your images will help a lot, generally though the smaller the size the better. Not sure what Omni-arts has been doing with the images I work with, but they were compressed a lot, while still being pretty good.

Optimize the collisions as much as possible, if you are doing a shmup, you might need to cap the number of bullets flying. One thing though is if you can don't add draw actor events to bullets, because that can be a lot more code that usually can be avoided with a create actor event. Not sure how you are setting up your level, but don't have enemies created until they are near to the view, and have them destroyed as soon as possible. If handled properly, there shouldn't be that many actors on screen at a given time. That's all I can think of right now.

I need to take a good look at my images. I think I save them in whatever without paying attention to them. I did not think it would be a problem at all especially since this junk celeron processor eats it alive. I think I have some bmps in there which are probably pretty bad I would imagine.

As far as collisions I think I should rewrite my whole shot code. Right now I have everything based on shots and the shots are doing all the collision checking and then when they hit something it checks if enemy or friend and determines if it hits them. It seems when several enemies (upwards 9-10) are on the screen it still runs fine but when the shots come in to play, it slows to a crawl. Just 20 shots on the screen will do that. So I am wondering if rewriting it for the enemies/player doing the collision check would be better.

I'll try to make a global code that limits all shots, for now I just have a trigger that says if there are so many bullets of the same type this enemy shoots, enemy cant shoot. But since its per that enemies shot, its really not effective.

Also I am using an analog joystick. I can't remember where, but I think I read that anything that uses direction/distance in a draw actor is a sizable cpu hog. Is this true?

Well that is pretty easy to test, but I doubt it. The logic for calculating for distance and direction is very trivial. If though you tend to use the same function calls for distance and direction, or any other functions, you can always store them in variables. Another thing you can do for testing is disable certain aspects of the game, or certain scripts. That way you can see what you need to work on most.

Damn, when I do get to iphone development I'm gonna have a LOT to optimize!

Yeah, its kind of a pain, but its oddly kinda fun. :X

I've made huge amount of progress by optimizing the pictures. Ive been editing them for a while making them 8bit and even down to 4-bit for the small shots. This has improved performance DRASTICALLY! This combined with a overall shot capped at 30 makes the game smooth as butter. I may not even have to rewrite the shot-code when I am done doing this

If anyone needs to know how I can explain for gimp. It doesn't actually let you save it as a certain bit depth so you have to make the mode "indexed."

If you dont NEED a transparent channel do NOT have one. GE uses the top left corner pixel for transparency so unless you want the whole image transparent there is not reason for the image to be 32-bit. If you need the top left corner for the picture just add add in some extra width and fill it in with the transparent color.

Okies! Open the image up in gimp.
Go to "image" then go to "mode"
In there click "generate optimum palette"
In the box with a number try to make it as low as possible without losing any quality. (Rather than trying to find the EXACT number use numbers like 8, 16, 32, 64, 128 and 256.)
Once done click "convert."
Then go to save your file. Save it as a PNG.
And it will automatically save it relative to what you set your index number to. (4-bit is lowest)

Hope this helps someone!

But when it comes to optimizing you should always strive to do better. Just because you don't have to optimize anymore doesn't mean you shouldn't. Of course, don't cut things out unless it is necessary, but if you can make it run smoothly with a higher cap, or none at all, then that would be even better.

Yeah, good point. I am just happy I got it to a playable state! I actually am still bummed I do have to cap the bullets. In the original concept build I had upwards 80 bullets flying around. So I will end up doing a test to see if the performance is worth the time to rewrite. If there is a significant boost I will definitely do it! Thanks for the help sky. I think picture optimization would have been one of the last places I looked. Also I getting rid of the draw commands I had in a few shot actors did seem to improve performance as well.

Quick edit! My shot collision code was crap! I moved the collisions check from the shots to the enemies and players and gained about a 100% boost YAY!