What I have learned about sub-apps

For a tiny game I wanted to slide in a menu using a sub-app in the actual game frame.
Here is what I learned:

iOS Devices:
- How you display your sub-app makes no difference. V-Sync on/off, display as sprite etc. everything is smooth.
- iPad 1st gen running 5.1.1 does not like sub-app's it kills the framerate. Old iPhone4 with latest OS runs fine.
- Display as sprite makes no difference for your fps, but it respects the layer it is on
- Hide/show makes no difference for your fps
- Ini's does not work, it works in fusion runtime though

Fusion Runtime
- V-Sync needs to be off, or your fps will suffer alot
- Using pause/resume will create artifacts when the sub-app is moved across the screen
- Display as sprite does not respect layers and your sub-app will be displayed behind everything. But it is fast even with V-Sync on


In general
- Pausing/Resume option is incredibly slow and not usuable


"Tested using lastest beta 8, and Direct3D 9, 60fps"

Awesome, good to know ! Thanks for sharing.

I don't use pause and resume in general. The best practice is to pause everything yourself. It gives you the most control.
This works especially well if you design all your own movements. Just place all your code in a group and deactivate the group when you "pause" the game.

This also helps the developer to avoid using things like subapps for things that can be accomplished by using actives in the same frame.

I don't like this method, it gets complicated when you also have to keep all kind of routines in mind which add/decrease values, check for input etcetc.. But without modal SubApps it's the only save and flexible way to pause. There's no Windows function I miss more than modal SubApps. Adding a reusable pause frame launched by a single line of code is elegant and effective. Now we have to plan every app with pause in mind, have to add all menue objects to the game frame and position them manually. Stoneage techniques :(

What are you talking about? It's not complicated at all. Extra "routines" are not needed nor necessary. Anything you do in your subapp can be done in another group that gets activated when you pause. If you have to write the code anyway what is the difference between having it in a subapp vs. having it in the frame itself?

And as you said adding a reusable pause (minus the frame part) from a single line of code is elegant and effective and possible using just groups as well.
Activate your pause group and have the group handle everything else.

I don't plan my apps with a pause in mind. I can add a pause to any app using my method easily. If you need help with it you can PM me.

UrbanMonk, could you please show us all an example of how to pause a game using your method?

Sure here's a video:
http://soapcow.com/video/pauseexample.mov

If you want code just make two groups.
One called
"Main"
and one called
"Pause"

Whenever the user pauses the game activate the "pause" group and inside that group deactivate the main group and handle your pause menu.
And vice versa for when you return to the game.

Thanks a lot!

So we all make games with a single moving sprite and everything's easy...

There are more than just one in that particular game. Example didn't show it well though.

Here is another example:
http://www.soapcow.com/action/actionslip.html

During the game press esc and you will see my pause technique at work. I made this game in 2005, but I didn't add the pause till last year. The game wasn't designed for the pause, but it still worked just fine. It took me 2 minutes to add it in.

Sure, it works, but imagine a complex game with pause menue, options screen, upgrade screen etc. - since you have to handle everything in the game frame it gets bloated with all kinds of objects. In your example the menu can be easily positioned and I guess it just contains non frame-following objects sitting invisibly in the first screen. Once you need whole screen layouts with nice background elements, AOs, strings and counters...I've done this, but it's really time-consuming to do all the positioning stuff on/off-screen manually. Extra fun is provided by multiple instances of objects like an OK-button required in all menue-screens. Also had some glitches when using qualifiers to start/stop anims and movement, so I had to touch every single object; another thing to keep in mind whenever adding new stuff, easily overlooked when editing a project some months later.

Nice retro shooter, by the way :)

I guess it depends on how complicated your project is.