Populate - OUT NOW!

That's weird, even with no other apps open I can reproduce this every playthrough at around level 33. That's the level where the fade transition is introduced. which brings the fps down at the start of the scene.

Are you using iOS 5? I've yet to test on a device that hasn't been upgraded yet.

iPad is iOS5, touch is iOS4.

I'll check out 33 later tonight.

If you think it's the fading - why not try to replicate this fading in a simpler case? Aasimar seems to also see issues with the fading, but it's unclear to me what that entails.

The behaviors in your game are massive, and it's not clear what the fading you're doing actually is. (I can visually see it but don't know what the impl is). If it's not memory related as you appear to suggest, then it seems to  be something you can replicate outside this game.

(Edit: And checking, memory appears to have nothing to do with this - it stays contant throughout the level as it fades in)

Minor nit on the iPad - the logo splash you put in doesn't have a big enough background.

It looks stunning, but the slowdown doesn't repro on my iPad presumably because the background never seems to fade on there.

The problem is the fps plummeting when it hits below a threshold, the fading is just helping it fall below the threshold (fading a 640x960 image is bound to cause lag).

The fading isn't caused by an opacity tween, it's drawn on with opacity with "draw image for actor". The fade code can be found in the behaviour attached to the background fade actor.

It doesn't work on the iPad yet because I haven't set up extra atlases to put the graphics into.

Without the fading backgrounds and balloons fading in the problem develops much slower and fixes itself before it gets to a breaking point (it's weird because it jumps from like 10 fps to 60 with no sluggish dips), however when the magnets are introduced the intensive drawing from them (that runs at not quite 60 when the problem isn't developed) cripples the game and made it pause for about 1 minute before it somehow solved itself and returned to 60fps.

Attached is something I noticed in the time profiler. As soon as the random lag starts happening objc::DenseMap gains a lot of running time and overtakes objc_msgSend. [SPView renderStage] makes up half of that, so maybe the render code is running every time it's meant to update? It would explain the exponential decrease in performance in scenes where graphics simply cannot run at 60fps. (fading two backgrounds)

There are multiple SPView renderStage items with high CPU usage in the other subcategories of DenseMap, so it probably takes up (a lot?) more than half.

Hmm......

http://forum.sparrow-framework.org/topic/performance-running-in-ios-5

This DenseMap thing appears to be iOS5 only, and based on the topic, it does appear that iOS5 isn't so good for this framework till whatever underlying bug there is, is fixed.

There is a workaround, but I'm fairly sure that it won't be satisfactory for this game and others. I can try it, but it will basically lead to some probable... I wouldn't say stuttering, but it won't feel as responsive.

I got to the magnets part (very cool when I first saw it), and on the iPad, it never stuttered once. How are you drawing those?

It doesn't look like the sparrow developer will get to it any time soon, so it would be good to try.

For the magnets I use lines. I subdivide a line between the magnet and the bullet into 5 or so points, then I offest each (except from start and end) by a random number. 2 sets of lines are drawn between these points, a darker sort of "outline" and a lighter, smaller line. In total it draws 8 lines per bullet in proximity to the magnet, so it can get laggy pretty fast if there are many bullets or multiple magnets.

I don't think the line drawing alone is really intense - it's a really basic implementation. Something else might be dragging it down.

Code: [Select]

- (void)drawLine:(int)x1 y1:(int)y1 x2:(int)x2 y2:(int)y2
{
    [mCurrSupport bindTexture:nil];
   
float mVertexCoords[4];
mVertexCoords[0] = x1;
mVertexCoords[1] = y1;
mVertexCoords[2] = x2;
mVertexCoords[3] = y2;

glPushMatrix();
glTranslatef(mDrawX, mDrawY, 0);
    glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(2, GL_FLOAT, 0, mVertexCoords);
    glEnable(GL_LINE_SMOOTH);
    glLineWidth(mThickness * [SPStage contentScaleFactor]);
glColor4f(mStrokeRed, mStrokeGreen, mStrokeBlue, mDrawAlpha);
glDrawArrays(GL_LINE_LOOP, 0, 2);
    glDisable(GL_LINE_SMOOTH);
    glDisableClientState(GL_VERTEX_ARRAY);
glPopMatrix();
}

I'll put up a test build with the workaround.

One thing that's really odd, as you've described is that it can randomly recover for no apparent reason. The same also happens if you flip away and return to the game (I saw this in Disorder). What happens there... I don't know if it's clearing some junk out.

The workaround definitely fixes the performance, it's constantly smooth and responsive.
The level share is still painfully slow but at least it doesn't die completely.

The magnets work fine for about 3 electricity draws then they start draining performance. The best way to test this would be to make a test game that draws like 200 lines.

The Teleports don't work for some reason, it seems there's a 1 frame latency between the bullet touching the teleport and it registering as touched, so it goes through the teleport, but then on the other side goes through it again because it doesn't think the bullet has teleported yet. I'm working on a work around.

Glad to hear performance is better! I'll keep the workaround in for b58, until I hear otherwise from the author.

If you could generate a test game that does the mega line drawing (preferably in a way that's similar to your game?), that would be great. Basic line drawing shouldn't be a problem, even if it's anti-aliased lines.

Good for me too ! you guys are amazing!

The Teleports don't work for some reason, it seems there's a 1 frame latency between the bullet touching the teleport and it registering as touched, so it goes through the teleport, but then on the other side goes through it again because it doesn't think the bullet has teleported yet. I'm working on a work around.

I have the same, 1s latency when my guy dies, but 60fps, so this can't break my joy, haha

If you can generate a unit/simple case of this, I can look into it.