Some memory questions

Is there a benefit to using alt values instead of counters?

What about Load on Call? The MMF2 help file mentions it for use with big image files, but will it help with ios apps at all?

What is harder to handle, large objects, or several small objects?

Xcode is telling me my game is running at around 11mb, which is well under the limits I've seen written about here as well on dev sites, yet it just can't seem to handle what I've put into it. The worst slowdown is occuring with multishot weapons where after a few shots the screen can have 20 or so bullets on it.

The stage starts off with around 86 objects. I've been hacking away as much as I can but I feel that at this rate I'm going to end up not being able to run anything other than a crappy space invaders clone instead of the project I started with.

I've read through the 'memory considerations' and other ios walkthroughs about 100 times now, so if anyone has come across anything that's substantially helped their game run that isn't in those, please let me know!

Here is a screenshot so you know sort of what I'm working on. It's an nes style shooter.

http://img62.imageshack.us/img62/5402/stage1b.png

is it slow when you test on the virtual device? or on the iPhone? what model phone are you testing on? the iOS runtime just plain doesn't work on the early model iPhones.. it doesn't seem like there should be any speed problems with what you've described/shown.

I think alt values are preferable to using counters, and smaller objects are generally better than larger ones. Keeping them in standard chunk sizes like 16x16 32x32 64x64 etc is more efficient I believe.

Game looks awesome btw ^_^

It's only slow on the actual device. The simulator runs fine. I'm using an 8gb ipod touch running os5. Brand new white one, latest build.

I'm going to switch as much over to alterable values as I can, since counters read as active objects.

I killed the left/right enemy sensors using a sensor free tutorial I found. That eliminated 24 active objects, but the boost was minor.

Another question, unrelated to memory, but could end up being major for me. After outputting the xcode file, would it be possible for someone with programming knowledge to go in and modify the code to optimize it in ways that I can't do through mmf2? If I can't sort these issues on my own, it may be my last resort to hire someone if that's possible. I definitely don't have the budget to pay a programmer to build the game from the ground up. . .

without seeing the code I can't really tell what the problem might be.. it certainly doesn't sound like you should be having speed issues, have you tested just a really basic game on this device? just a few actives and events.. to see if it still runs slowly?

one thing to watch out for is fastloops, you have to be very careful with them in iOS.
edit: also if you must use counters, making them hidden (not number display) may help a little, not sure on that though.

as for getting a programmer to modify the code... I'd say that's not very likely... it'd take him a very long time to decipher all the runtime code.. he'd probably never be able to make sense of it.

I have had results getting things to run pretty well. During first testing of this game it ran smoother, but it was very basic. Only a single bullet weapon, 1 character, very limited amount of background graphics. The thing is, the allocations haven't changed much at all. It's hovered around the 9-11mb mark since the beginning. I'm not pushing the hardware to its limit or anything, they've got Grand Theft Auto 3 running on the same device. I understand that there's different technical aspects going on behind the scenes, but I'm starting to feel like I'm running out of ways to optimize it using the tools I have in mmf.

I only have a couple fastloops, and they use very few loops, I believe I tried taking them out at one point and it didn't make a big impact, but I'm planning to try it again, and see if I can figure out how to get it running without them if it does help.

All my counters are set to hidden except the health and weapon ones you see, but those are graphical and not numeric (which seemed to be the problem mentioned in the docs)

I do imagine it'd be hard for a programmer to make heads or tails of it in a reasonable time frame/cost, but I figured since the runtime is geared towards running games in general, maybe a tailor made fix would be rather simple. I'm not a programmer of course so I have no idea. . .

We have impleented a colision detection acceleration recently. It might make your gam faster. It will be published in the iOS user Lounge soon.

Looks like a great game! If you sort out your memory problems I can't wait to play it!

Have you tried setting all of the active objects to be inactive if too far from window? I'm not sure how much that affects the iOS module but in past PC games I've made it's been the difference between 15ps and 50fps. Also are you destroying bullets as soon as they leave the screen?

You could also potentially split your levels over multiple frames and use transitions, like they did with the iOS version of MegaMan X.

Maybe add events to test that your enemies etc. are within the frame area before they do anything. Try condensing all 'Always' events into one, I often find that increases the efficiency.

What fast loops do you use? I try to avoid them altogether on iOS games if I can help it. The one time I tried to port a static platform engine of mine the fast loops pretty much killed the game. Of course that can be difficult with collisions, particularly on platform games where without fast loops the character will land 'in' the floor and it looks clumsy to have to 'push' him out, but I find the Advanced Platform Movement Object to be pretty damn good at doing what I want.

Our game runs very badly and crashes on the brand new ipod touch we bought in december, however works flawlessly on the ipad 2 and iphone 4/4s, not sure about ipad1 performance.

I would be very interested to know what the market share is between these devices. I would suspect the majority of people buying apps *are* using the iphone 4s and ipad 2.

Personally we are just focussing on targetting the high end apple devices and including a disclaimer that the game will not work on ipod touch.

Not that we consider ourselves to be in the same league as cave or square enix, i believe they make similar disclaimers.

ANOTHER thing to consider, is that you can initially release your game JUST for the ipad & ipad 2. If it is well recieved, then spend the time cutting back to release a ipod touch friendly iphone build.

Game looks awesome, good luck.

What version ipod touch is it, 4?

Also are you building the project in debug mode?

DistantJ:
I have several objects set to inactivate, but now that I've eliminated enemy sensors, I will check that those enemies inactivate.
Bullets are destroyed as soon as they hit the edge. My levels are 'relatively' short already, but that's something I'm considering. I'd like to avoid it if I can though.
Certain enemies are created based on the players position. i.e, you reach 1000x so enemies between 1500 and 2000 are created.
I have now eliminated all fastloops. I use a sensor below him to help avoid him sinking into the floor to begin with. That's the way I did it before I discovered fastloops, and while it's not optimal, it works well enough.

CfullerNY:
Limiting to ipad/ipad2 is a possibility, but a last resort. Plus, I'd have to go out and spend $500. I've already sunk quite a bit of time and money into development so I'd hate to spend MORE money while at the same time limiting my potential profits.

Bigfoot, Assuming you're talking to CfullerNY, but mine's 4th gen and I'm building in release mode.

Thanks for the tips everyone.