What would you all consider a framerate to aspire to? My app runs at about 15-20 FPS on a 3G. I really need to get some opinion on this, as I can’t really seem to get it any more efficient.
What do your users consider acceptable? Would 15-20 be too little?
Thanks
the more the better 
go for 60 and you will be fine hehe ^^.
well I am not a coder guru , but i believe that if you can get a 30 " stable" fps all the time you should be fine.
after what kind of game play also in the balance , maybe a quizz game will run enough at 15 / 20 but for a intensive shoot them up game that will maybe a bit to little as you said.
Anything under 30+ is generally considered ‘Choppy’.
Anything under 20 is ‘laggy’
Anything under 10 is ‘crap’
As long as it looks and feels smooth enough, the actual numbers do not mather. But usually, it probably won’t feel smooth with a 15-20 framerate.
i always hunt for 30 FPS on a 3G - but as soon one got more than a few distinct objects and skinned chars onscreen this is a hard target.
But via optimizing for batching there’s always a chance for a few more frames…
Hmm what code you use to counter FPS? I use this code:
if (Time.timeScale != 0.0)
{
var fps : int = 1.0 / Time.deltaTime;
guiText.text = fps.ToString();
}
and don’t have more than 30FPS on my iPhone 3G… I can have simple box on scene and max have 30 FPS…
What else are you using? Potentially ongui etc?
I have 3 guiTexture + 1 guiText (for fps counter) + simple box + camera - without any scripts and max 30fps…
Edit: I do test… I disable all without camera and guiText… and nothing change… 30fps max 
The FPS is capped to 30, but you can change it from the AppController.mm in the XCode. (the #define kFPS or similar).
Yes, that would be the Kfps.
Good news is I found out how to improve it. Things are definitely steadier now - it was the CPU hogging stuff.
I’ve worked in the games industry for about 10 years. I’ve developed an opinion based on some empirical data so take this with a grain of salt.
One of the big publishers I worked for spent about 20k on focus testing this very issue. The verdict was this: maximum absolute frame rate is irrelevant. Even the die-hard-peg-at-60-or-bust ratchet and clank guys have come off of this stance. The next R and C will be at 30. In fact, running higher could hurt your reviews. A quick explanation: we submitted a build to the group of a FPS that went on to sell over 3 million. We had a variable frame rate and in some areas we would hover from 40 to 60. We got dinged on scores due to some groups saying it was laggy in some parts especially if a lot of effects (read: particles)were spawned. We resubmitted a build and pegged the rate at 30Hz. This is the important part: we received better scores across ALL groups. The game play and experience were both rated higher. The moral of the story was that people are more concerned with perceived frame rate. Drops or huge deltas in the rate is bad. If you stay at a constant rate, even if it’s lower, you’ll be better off. People will get used to the feel of the game at that rate and won’t feel any deviations.
It’s like driving on 80 on a highway and slowing down coming into a town to 50. It feels tremendously slower. But if you have been driving in neighborhoods all day at 25, speeding up to 50 seems like you are flying. It’s all relative and it’s the delta’s you should be concerned about.
So besides consistency, there’s one other big factor: the type of game you make. If someone says this framerate or that framerate is good/bad without knowing what kind of game you are making, I’d be wary. Card games do not need the same frequency as shooters. You don’t need 60, 30, and can even get by with 20 for some types of games.
Which is why the “average frametime” value on the profiler is more important than Max one 
The N64 ran at 20fps, or at least some games did, like Legend of Zelda: Ocarina of Time, and nobody complained about that. Indeed it’s more important to have a consistent framerate than a fast framerate. (Although ideally it’s best to have both if the hardware can manage it…I was playing around with Quake 2 some years ago, vsynced to 120fps on a CRT monitor, and that was a dream as far as fluid gameplay goes, distinctly nicer than 60fps.)
–Eric
For some players, was even more than a dream : it was a requirement 
I even know someone who turns off every textures of the game …
“Textures are useless in quake”.
:lol:
Thanks for that insight, GhostDog. My main problem is that the framerate drops when AI is active (note: all the time). I think that I can crack it, however. Instead of updating the AI movement all the time, I think that maybe making it look a little jerky in an attempt to recover FPS is something my users won’t mind
Quake gained nothing with textures, it was just extra edge detail your brain had to process, which potentially made it harder to see enemies you wanted to pwn with a rail.
Start breaking down the problem in pieces. Then for each piece ask questions like “what do I know about this piece before I even start the game?”, “what do I know before the encounter?” or “what do I know about the AI before they spawn?”. That gets you in the mode of thinking about tasks and information you can pre-cache so that at run time, it’s available. Then you get to solve the fundamental computer science problem of all time: speed vs memory. Balancing storing that information versus computing it on the fly.
Profile your algorithm as well. There’s probably some areas in your movement code that could be simplified. In fact, you should already have budgets for your systems (and subsystems!). If a module goes over budget in terms of it’s share of the frame then you address it. Approach it the same way you do with data, identify chunks and start breaking down problem. Never start with the details. Go from big to small.
It’s not a silver bullet by any means, but once you start thinking along these lines, it makes it easier to maintain your frame rates. Plus it’s a good way to stop feature creep and stay focused. You can justify not putting X feature in because it makes the module go over budget.