Populate - OUT NOW!

If you can, get hold of an older version (b50/51) of the engine - via what was sent in an e-mail or whenever, just to make sure.

Just as good practice for testing, hold on to the last couples version - it's crucial in situations like these. I'm still extremely skeptical that the OS is the problem.

I keep all zips of iStencyl, I just don't label them by version. I can judge my way back to b50/51 by counting the zips back from b54.

Thanks. Let me know what you find.

Here are some observations on memory. I wasn't able to really evaluate performance because I don't have the iOS 5 SDK yet, so I couldn't put it on my iPad. I did test it on an iOS 4 iPod touch, which couldn't get to the Arcade due to memory, but was able to run in the level editor, which baffles because the level editor uses more.

- There are longer then ideal times when the screen is pure white between scenes. I haven't seen this happen with other games I've run.

- Memory usage is odd. Entering credits jumps it by 4 MB, OK. Returning to the menu doesn't reclaim it. Re-enter, and nothing further is lost.

- Game loads - 29 MB. Enters splash 18 MB, then back to 30 MB. Interesting pattern to have it dump memory only to load it back again.

- Level editor jumps by 9 MB, exiting doesn't seem to reclaim anything. In fact, it does up by 1 MB. If I re-enter, it jumps up another 5 MB, leave it does the same thing.

- Entering arcade mode jumps by 7 MB. Exiting reclaims 4 MB. Rentering jumps by another 7 MB., and you can see where this is going.

- Similar story for Level Share.

- Memory usage once you're in the game is steady and properly clears out after each scene.

- I notice that some atlases stuff iPad and iPhone graphics in one.

We ought to get to the bottom of the memory situation. It could be bugs on my end, or it could be on yours. The general problem isn't really that it's high (it is, but that in itself isn't a problem), but that it's not able to reclaim it all and actually is worse, in a sense because it tries to load over and takes up N times the memory.

So the gist of is that we should figure out the simplified scenarios in which this occurs, and then that's something I can work off of.

As for performance, I'll let you test locally with the various older versions and get back to me about that.

Memory might be dipping because of music, it's the only reason I can think of memory being lost from the credits of all things. This is probably where the memory is lost in arcade mode too, as I make sure I unload every atlas other than the main menu when returning to it.

The only other reason i can think of is atlases not unloading.

Since it seems like you're able to run Instruments now, could you run some simple tests to see whether you can replicate the scenario I saw where loading a new area, exiting and re-enering would lead to leakage?

e.g. jumps by 10, drops by 5, then jumps by another 10, etc.

If you can get that to happen in a simple case, that's something I can work off of tonight. Thanks!

I'm in england until tomorrow night or the morning after. I can see if I can crash the game through memory usage by doing that though.

I can't crash it here no matter how many times I start and close arcade mode. The white pauses are because I don't switch as soon as the white becomes 100 percent opaque, which I mean to change.

Oh, I know why it's not crashing for you - the iPhone has twice the memory as the g4 touch.

The crash's cause is the memory usage, and wanted to figure out some simple cases for reproducing the leakage problem I found.

(We still need to figure out the performance issue. If you test the game as is on the iOS 4 models and it's still slow, then it's something recent.)

I can confirm that there's been some sort of regression in the atlas unload functionality. Before, the book example's memory held steady. Now, it seems not to unload at all. What's saddening is that this is really hard to track because that particular file that does the loading/unloading doesn't seem to have changed in a long time. I can't figure out what else would affect this.

I bet that this might also be why the game's performance suffered. It goes degrade as you use more memory.

http://community.stencyl.com/index.php/topic,4332.0.html

Maybe the Fix for (or cause of) this?

Nope, that was just a typo in a printout. This one's proven to be the toughest nut to crack so far. I wasn't able to fully track it down after several hours. Attempting again now.

I bet that this might also be why the game's performance suffered. It goes degrade as you use more memory.

This is probably it. The game accumulates lag up until a point where it all just goes away, which I bet is garbage collection for logic memory usage. Maybe iOS5 lets it get closer to critical before closing it, or maybe it doesn't close it at all.

There is some correlation between touching and the images being retained. And it gets more complicated than that.

I fixed it for the backgrounds case (backgrounds don't get touch events). It didn't afflict the normal actors case, but it's affecting the case where you pick a different atlas per animation.

It's going to take days more to pin this all down - I've never had to sink more than a day on a single bug, and this is the very first time that's happened. Lots of more subtle cases leak (this is all for loading/unloading atlases, not for games that don't do it)

I fixed the more obvious cases where even backgrounds were retaining (due to touches - not really our fault), where plain actors were retaining their graphics despite themselves being destroyed (very, very subtle one).

I've now discovered through this game that recycled actors cause graphics retention too - in ways I haven't figured out yet, but I believe it may be because recycled actors aren't auto-killed when the scene exits.