Serious performance issues (iOS)

[Kalladdolf]

I've been working on a couple of projects for the iOS platform now (mainly iPhone),
but put them on hold / cancelled them right away after the first round of testing them on my iDevice.

I am using the following:
iPod touch 2G
Disk space: 16 GB (30% full)
Memory: 116 MB
CPU: 533 MHz
iOS 4.2.1 (latest for the model)

I test my projects using GE player (AppStore version).

Now, about my problem:
Anything I test on my iPod is as much as unplayable, as the framerate drops below 1-5; certain lag even causes the engine to skip a ton of frames
which causes all sorts of collisions and other events to mess up.
I have tried all sorts of different things, such as:
- Minimizing screen movement
- Activation regions
- Turning motion compensation on / off
- Removing all collision events
- Destroying actors outside of view immediately
- Using the smallest possible sprites / crappiest file types

Now, I'd really like to know whether that is a general problem, or if my iPod has some sort of uneasiness with GEPlayer (mind you, even pyrometal's epicman demo doesn't work properly,
the lag makes the person go through walls), or if the engine is too heavy for portable devices.
I'd really like to continue those projects, but with this major problem in the way, I don't see a way how I can go on.
Thanks for your help.

[jimmynewguy]

That's really odd. I've only used the geplayer that wasn't in the appstore and only had lag with lots of actors using draw actor codes that were quite long and I also used an iPod Touch 2G. I used photoshop for all my graphics and exported them for web and mobile devices and had motion compensation on with activation regions. But it seems you tried all of that. I do however have iOS 3.1.2 that is jailbroken with a bunch of unnecessary extras that slow it down, so really yours should work better.

Maybe try this really crappy game I started making for my iPod that tested at 30 fps all of the time. If it doesn't work it could be something with the geplayer (which I would think it would be opposite) from the appstore or your iPod.

In the game just chose the first bacteria research as the level (or else nothing will really happen)

[Kalladdolf]

Thanks for the example.
It ran pretty smooth to start with (which really makes me think that screen movement is one of the main factors).
Of course, after a while the framerate was reduced proportionally to the bacteria clones on the screen.

[HitoV]

I am not sure what type of game you are making but...

You might want to try to check out this thread:
viewtopic.php?f=1&t=11005

Sky gives some great advice and I list most of my test results here.

Also this is a great reference...
viewtopic.php?f=2&t=7457&p=52317&hilit=looping+music#p52317

It should take you to a post from DST that has some optimizations ideas. Keep in mind that these are meant for pc so a few things do not apply. (Picture compression and music.)
When I first tried a build of mine on the ios I was so discouraged and sad But over the course of a weekend I was able to recode several things and make it run damn near full speed. (At the cost of losing a few cool special fx... but oh well.)

Let me just copy and paste my beta test page doc. These were my major findings in my particular game: (shmup type game)

* Optimized all images to be as small and efficient as possible. All the pictures were in 32-bit but most of them could be converted into 8-bit with no artifacts. This moderately increased the speed of the game. Overall added about a 10% increase to fps. I also cut down a few frames of animation on all explosions and other things. (All PNG's)

* Re-wrote shot code. This was by far the biggest gain in FPS. Instead of having the shot actors checking for collisions each frame I re-wrote it where the enemies and players do. This results in much smoother fps because at most you have 10 actors calling the massive collision code every frame. Before you had 20-50 bullets on screen calling for it and it slowed to a crawl. This created LOTS of problems but mostly all of them are fixed and it works like before now! Overall added a whopping 200% increase to fps.

* Unfortunately one thing that impacted performance a lot was the music. Ogg's and mp3's actually do take quite a bit of cpu power to decode thus costing the game FPS. I have found that .wav files (although much bigger in size) do not need to be decoded therefor have no impact on the cpu/fps. My solution is to make songs shorter and loop them. Most would be only 1:00 to 1:30 long. Overall adds about a 20% increase to fps at cost of lower quality music + larger file size.

I hope this helps, if you'd like I can build you a file of the first level of my game that you can try via geplayer and see how it works on yours. If you want me to test out yours on the touch 4G I can as well. Good luck!

[akr]

Thanks HitoV. Great observations!!!

[Kalladdolf]

Very happy to hear that there still is hope.
I'll get started right away on the things I haven't tried yet.
Thanks for pointing those out to me.
+1.

PS: Concerning what projects I had in mind, this would be one.
Still fiddling with my glitched engine itself (trying not to use collision detection at all). It's a bit of a challenge since the robot moves pretty darn fast.

[HitoV]

Np! Thanks for all you have done akr!

Best of luck Kal! I checked out your game demo and that is very cooool!!! I know I will LOVE the finished version!

The physics are somewhat similar to a game I have just started. I was able to get mine to run at 60fps on the touch 4g. Every object I have in the game now is only a few colors but I seriously doubt that adding in a few new sprites/animations and changing the tiles to 16-bit pictures would cripple performance. Remember that collision with "any actor" is your worst enemy. Stay away from it if possible and try to put the collision code into the objects that will have the fewest actor count on the screen. For that particular demo I would just have it in the robot, not for all the tiles.

I pm'd you a link to a demo level you can try on your touch.

[Kalladdolf]

Your demo runs smoothly without any lag.
Thanks for that. Now I kinda know which way to go.

In that 2009 demo of T35Tbot, I used several child actors around the main character as additional collision detectors for a more accurate detection.
Unfortunately the more collision sensors I have, the more it'll slow the game down.
I'll try evading collision detection altogether by letting filled regions detect the actor's position / velocity and act accordingly to it.
So far pyrometal's been the only one who's had success with coding his very own physics engine, but I'm giving it a shot.

:3

[akr]

It really looks like performance is pretty much affected by collision. So I experimented with 1.5 yesterday.
GE has a pixel perfect collision detection. This means that pixels of sprites get compared when their rectangular regions overlap.
Therefore a pixel mask gets computed once. Its not the calculation of the mask - it seems the comparision of the masks is the root cause.

So in 1.5 there is an additional collision system introduced. This is event driven. Each sprite gets a wireframe drawn around as
collision boundaries. The wireframe polygons are not pixel perfect. Means that e.g. the polygons drawn a round the ge pacman
actor do not consider the pacmans mouth as a non-collision region. Its because the polygons have to be convex. But that
doesnt matter much. All my tests with the generated polygons were ok. About 40 polygons get generated to describe the ge pacman e.g.

So this means that the new collision algorithm has the performance of f(x). not f(x^2) or bader. Its based on a event driven
collision called "contacts". You can read further on box2d.org if u are interrested.

But so far only dynamic actors do collide with other actors. Static and kinetic actors dont collide with each others. So I thought
maybe we should introduce static actor collision....?

[Kalladdolf]

Yes, for most platformers (unless the gameplay is physics-based, like Portal flash), pixel perfect collision is actually pretty counterproductive.
I can remember that in the past few years many of us have posted several demos in which we tried to find a way to make games more "unrealistic" in a sense that we e.g. didn't want our actors to slide off edges.
Maybe it would be a good idea to have two options for collision detection:

Code: Select all

- Pixel detection

                      /--- box collider
- Shape detection ---  --- other basic collider shapes (sphere, triangle etc.)
                      \--- draw custom shape (probably not that necessary...)


Also, what I forgot to ask ( I could test it for myself, but frankly, why reinvent the wheel, when someone else may already know it?):
What color depth do you recommend for the environment art? 20 colors?
At the moment, my tiles have a size of 40x40 and I have 21 colors altogether (including the pink transparency fill).
The image file where they are stored is 600x320 and growing, so atm we're talking about 120 tiles. I'm still working on them so there are probably going to be twice as many.
Plus background tiles which are going to consume just as much space.
How well do RGB values on the platform tiles work (if I make all tiles as light as possible and for different levels / ambient lighting I'd use rgb values)? Would they also slow us down?

Also, how do I optimize the loading process (like implementing a loading screen and therefore having a smoother transition)?

[HitoV]

That is awesome akr! I'd love to test the new collision system out and I could benchmark it too if you would like. (something like this http://www.youtube.com/watch?v=6kUtq4JjkFQ)

I think that what kal said about shape detection would be great. Specifically:

"other basic collider shapes (sphere, triangle etc.)" Most actors in my games would be fine just using these.

I wish I could help with some of your questions Kal but I actually would do not know the answers. As far as what bitdepth, I just index the colors and gimp automatically sets the bitdepth itself. As for 21 colors I imagine it would save it as a 4-8 bit picture. Try saving it as 4-bit, (if you're using PS) and see if you notice anything not right. If not good, if so 8-bit should be your baby.

I would like to know this too if someone could enlighten us
"Also, how do I optimize the loading process (like implementing a loading screen and therefore having a smoother transition)?"

[Game A Gogo]

21 colors is such odd in computer terms, usually palettes goes from 2 colors, 16 colors, 256 colors, 24-bit and 32-bit S:

[Kalladdolf]

Well, I guess it'll be 256 then.

Oh, one more thing: In the iOS FAQ section it says that for retina displays you need to adjust your game to the new screen size.
I have set up all my sprites for the old screen size (480x320 landscape). So would I need to scale everything up (I'm doing pixel art, so there is no point in / I would mind not having retina support)
or would my game also automatically show full screen on iPhone / iPod 4 (which would be great)?
If I had to scale everything up, the level design would take ages (since I draw tiles).

I actually still have a ton of questions, but if this gets a little overwhelming at this point, I can list them in another post.

[Hblade]

AKR:
The performance (from what I read) has to do with the frame-updating method of movement between actors, (OpenGL will solve this in the long run), and as you said, the collision. The "Physical Response" and the "Per-Pixel" collision will cause strain on low end processing units, such as iphone. (Heh, Iphone is most absolutely NOT low end but hehe you know what I mean )

I'm not a programmer so I wouldn't really know but thats what it sounds like

[jimmynewguy]

That is awesome akr! I'd love to test the new collision system out and I could benchmark it too if you would like. (something like this http://www.youtube.com/watch?v=6kUtq4JjkFQ)

Off topic slightly, but can I see the old/new code for comparison? I like to look at things that work well and compare it to how I would do it!