Extreme Lag on Older Devices

Hey guys, another problem I've come across recently.

My app, a basic Minesweeper, runs EXTREMELY laggy both in Menus and in-Game. Occasionally it can lag up to 5 seconds between frame changes.

Problem Devices
iPod Touch 3G/4G
iPhone 3GS

I tried other games made with MMF2 (Plasmatron, Pocket Ninjas) on these devices, and while they ran slower than a 4 or 4S, they were WAY less laggy than a simple Minesweeper game, where the only "action" on-screen is clearing blank tiles out of the way, and super basic transition-less menu frames.

Troubleshooting
1. Are there settings in Xcode that might be the cause?
2. I notice some frames run at 35mb, how is that in the grand-scheme of things? Could that mean a memory leak in MMF2?

Final Note: The app runs mostly well on a 4S. Only 1-2 second frame-change lag.

Thanks,

Verbage

I specifically bought a iPod 3G since I wanted to make sure my games ran decently enough on older hardware. Stuff I make that runs at 50fps will run as low as 20 fps on the 3G. It is a marked difference in hardware.

Today I managed to buy back 10fps however, since I found a single event that was always running, instead of only once per mouse click.

How many events are on your frames?

Heres a trick I learned: Make a counter in the frame, and then in some event in your event editor, add a line that adds 1 to that counter. When you run it, the speed that the counter increments will tell you how often your event is running. If its an event that selects a lot of objects, it could easily cause a slowdown.

You can also try deleting the bottom half of your events and see if the framerate recovers. If it doesn't, delete the top half. Continue bisecting until you find events that eat up the processor.

I'll try eliminating all "Always" events. That could be an issue. But still, these are highly basic menus and lag is unbelievable.

try downloading the most recent build in the forum. also set xcode to build instead of demo. these things killed the lag in my games.

I'm always on the most recent build. I'll try to locate and change the build setting.

The "debug"/"release" toggle is under project settings under "Info" correct?

You may already know most of these tips, but these are some things to keep in mind:

size of your graphics could contribute to putting older devices under stress. Keep them as small as possible and as close to the next power of 2 in width and height (eg: 8, 16, 32, 64, 128 256, 512 pixels wide/high etc).

Use the colour reduction mode. You can override it on specific objects as needed.

Don't make a retina resolution if you are planning to support really old devices if you can help it. MMF has to scale these down and memory is smaller on the older devices.

Avoid Fastloops running all the time where possible use MMF events and built in functionality.

Set FPS to 60 or 30.

Keep things simple, try not to over complicate a feature - you can still make it do what you want but there is always a better way.

Test while developing on an older device - it helps highlight what changes you make cause slow downs.

Use timer based movements if needed (either MMF's built in support or code your own - I posted an example some time ago) - This allows you to keep the appearance of speed with moving/animated objects when the frame rate drops.


I test on an itouch 2nd and 4th gen devices. I find the 2nd gen is limited, but it is possible to keep things moving really fast and MMF works well in general.l

Object selection is really slow compared to PC, if your grid is made up of 12x12 objects, and you're testing them via object selection, that could be the cause. I'd recommend doing all object testing (number crunching to find nearest bombs etc) via the array object, and then transfer the results back to the onscreen object when you need to update it visually. The advanced game board object may be another solution (if you're not already using it).

Are you using fastloops?

Only necessary fast loops that draw bombs as the user reveals the first tile (required for a safe first reveal). I can look through my Event Editor again, but I cannot go without that fast loop.

I should clarify: My actual game is not very slow at all. Just the menus and transitioning between frames is unbelievably slow.

How did you implement the menus?

Ive been having a lot of luck by using the layer object. In-game, if the player requests the settings menu, I unhide a dedicated layer for it. I also close a group of events that controls the game engine, and I open a group of events dedicated to the menu buttons.

This way, the events for the menu are only active when needed.

If you're referring to buttons that are always visible however, then you need to keep them visible and active.

Have you tried setting the optimization level for debug to "fastest, smallest" in Xcode?

kinase, do you have an app on the app store that uses that method? I would TOTALLY setup my app like that as long as I can see it in action.

Yeah, my golf game does it. Here's a promo code for you:

YLPXA6EJ9FMH

The menu/scorecard is on a completely separate layer. On a level, you activate it with the button on the bottom left.

Here's what a basic event structure would look like

HTML Code:

---


+ User clicks on menu button
+ Menu layer is invisible
          > Deactivate game group and activate menu group

Game group :
    Your game engine stuff

Menu group:
    + User clicks on menu button
    + Menu layer is visible
          > Hide menu layer
          > Deactivate menu group and activate game group
    + Only one action when event loops
        > Show menu layer
    + User clicks on some button in the menu
        > Do something




---

In the game, whenever the scorecard is open, you can't aim or take swings. This is because my game engine is getting deactivated. Furthermore, because the events handling the buttons of the menu are in the menu group, they wont work unless the menu is visible. This is important, otherwise touch events will cause actions even with an invisible layer. This also saves you compute cycles if you have a big complicated menu system.

Why do I show the menu layer in a separate event? This is due to the true event driven nature of the 'user clicks on object' event. Without having separate events, a menu button click will deactivate the game group, activate the menu group, and then trigger the close event instantly. The staggered events delay this action it to prevent this instant deactivation issue. In this case, order of events is critical. The layer must be shown only AFTER the condition in which clicks and layer visibility is checked.


If you can't get it working, let me know and I'll try to create a minimal example for everyone.



EDIT:

Here's another thought I just had.

In-game menu's tend to be rather large, in terms of screen real-estate. If you need to make them appear out of nowhere suddenly without changing frames, and you're NOT using layers, then the only way I can think of implementing this is by changing the visibility of a big active object to serve as the menu's background ....

Is this what you are doing? If so, I imagine that would be slow, since actives have a lot of overhead. Keep in mind that the black menu you see in my game is simply a quick-backdrop with partial transparency set to make it look nice. Layers are neat since they are the only mechanism I am aware of that let you dynamically show or hide any kind of backdrop objects.

First off, awesome game! I was really impressed with your physics and gameplay!

As for the layers menu system, it works SO MUCH FASTER! I get instant changes!

Thank you SO much!

Glad to hear! I'll have to cook up an example then. I think this simple technique will make development a lot faster.

Thanks for the compliment. The game hasn't been a great success. A lot of my friends have been rather critical since it isn't realistic :p
Ive never actually played golf ....

Nonetheless, I have a free iAd supported copy hopefully coming out soon. I hope to make more than $100 over the course of the games lifetime, which will be better than what the paid copy has accomplished.