Active Objects are used in almost every MMF game. Unfortunately, when used in large amounts, they tend to cause slowdowns, especially on slower machines. There are, however, many ways to optimize them.

In addition to all the “normal” optimization methods, such as smaller size, using VRAM, box collisions etc., the Active Objects can in a way be used in “passive” or “active” mode.
Now, the speed difference between the “passive” and “active” ones is HUGE. This is why it is important to make sure you use “passive” objects whenever possible. On a test application with lots of AOs, I was able to find out that on my comp, the “passive” ones are at least 5x faster!

These two modes automatically change when things happen. Basically, when the active object does something graphical, it goes into “active” mode. It’s not always that simple though. Here’s a short list on some things I’ve found that change the active object to “ACTIVE”:

-Moving the object (even if it’s the same x/y so that it does not visibly move)
-Animating the object (right after the anim is over, it goes to passive. If stopped, also goes passive)
-Scrolling (with or without VRAM)
-Changing the object’s animation frame manually (important to note - stays active forever)
-Changing the object’s direction (can also sometimes stay
-Basically everything that changes the object graphically

Here’s examples of things that DON’T change objects to “active” status and thus can be used freely swith the “passive” ones without sacrificing much speed:

-Alterable values, flags, etc.
-Checking collisions with other objects

So unfortunately, “passive” objects aren’t really possible in all applications. This is probably reason why many times it seems that when the screen is stopped, it runs fine, but slows down when scrolling – the objects go “active” when it starts scrolling. (another reason could be that VRAM is not ticked).

The “change animation frame” is a nasty one. All you have to do is “start of the frame -> change anim frame to 0” and the object is at least 5x slower for the whole time it exists, even if it only had that 1 picture. The picture probably keeps looping or something. Even if you try to “stop animation” after that, it will have no effect. The only way I have found to overcome this slowdown is to wait until the animation is finished and then change the frame manually. This time the object stays passive after the frame has been changed. Another way, of course, is to not use the handy “change animation frame” at all.

The “passive” AOs are kind of like “active backdrops”, being pretty fast but not having so many options. They do still have some advantages over backdrops, like the values, collisions, qualifiers, can be destroyed in runtime etc. They can be very useful for games that don’t scroll, for example an inventory with lots of slots, or a card game where most of the cards don’t move. You just have to make sure they are actually passive when they don’t move (no looping animations etc.)

If you want to test this on your machine, just create an app with lots of static AOs, like 500. Test the app with a FPS counter, then create an event to change animation frame at start and compare the results.

Many games will unfortunately gain no boost from these optimizations. The basic idea is that if your game is scrolling or most of the AOs are moving/animating all the time, it’s useless to try to make the objects passive. On scrolling apps, it’s probably a better idea to do the static objects as backdrops, they don’t take much of a performance hit there. Take a note that if your game is scrolling and you want to use AOs, you might as well animate/move them too, since they are already “active” because of the scrolling, so you won’t see much of a speed difference anyway.