How many loops does it take to slow down a game?

[D_Light]

I remember seeing a few posts talking about how to optimize a game and I remember someone saying that running too many loops will slow a game down.

So how many loops can be run at the same time before the game starts to slow down?

[Popcorn]

That depends on various thing, like for instance what the loop does, and how often the loop is triggered.
You can run a loop that does nothing as a million times, and it probably wouldn't slow down your game. But as soon as you add an action on each loop, you will notice a slowdown. The more actions you add, the slower it will be. Some kind of actions takes longer to execute that others. For instance will reading text take longer time than reading numbers. And writing takes longer time than reading.

System specs also is a factor here, and what runtime the game runs on. A perfect fastloop in a windows app might not be as fast in a flash app.

So there is really no good answer to your question. You'll have to find out the boundaries of your game yourself.

[D_Light]

That depends on various thing, like for instance what the loop does, and how often the loop is triggered.
You can run a loop that does nothing as a million times, and it probably wouldn't slow down your game. But as soon as you add an action on each loop, you will notice a slowdown. The more actions you add, the slower it will be. Some kind of actions takes longer to execute that others. For instance will reading text take longer time than reading numbers. And writing takes longer time than reading.

System specs also is a factor here, and what runtime the game runs on. A perfect fastloop in a windows app might not be as fast in a flash app.

So there is really no good answer to your question. You'll have to find out the boundaries of your game yourself.

Thanks! For the most part the loops I'm running will be moving objects around, and only if they are on screen. I was worried about having too many loops running even though they aren't doing anything.

But I guess that won't issue then hopefully.

[Pixelthief]

Its not so much a matter of just how many loops or what you do, as much as how you structure your loops. Every time a fast loop is read, MMF2 reads every single visible (in open groups) event with a "On Loop" and compares to the string, for example if your loop name was "Loop1", it needs to take the loopindex and compare it to the "Loop1" string one by one, each line. If you have 500 loop events and run a single loop 200 times, you have 500*200 events read, each one comparing its string and with the overhead of MMF2's event editor interpreter (far bigger issue than string comparisons).
But if you hid 499 of those loop events in closed groups, and had only the 1 relevant event open, you'd only run 1*200 events.


So its quite possible to have a project where you have thousands of different fast loops and functions that run thousands of loops each all in the same frame and not have any real slowdown, so long as you make sure MMF2 isn't reading any more events than it has to. As a general rule, you want to keep your "on loop" events hidden in closed event groups, and sandwich your every "start loop" action between two calls that say "Open group" and "Close group", like in this image:



Here the "On loop "Load Level"" is within group "Load Level", and calls a different fast loop inside "Export Gravity Zones"
So I close the group the load level loop is in, open the gravity zone loop, start the loop, and when its finished it returns to this line, closes gravity zones and opens level loading
If I didn't open and close the group, every iteration of "Load Level" would have to compare to every event of "Export Gravity Zones", and vice versa.



These kinds of optimizations make all the difference in the world. An unoptimized project might go terribly slow even with just a relatively minor loops if you have a large project with many different loops, whereas this application of mine is 10000 lines of code long and runs at 120 fps even while invoking hundreds of different loops each frame for many iterations.

[D_Light]

Thanks for the response! I'm not sure I fully understood everything you said though. What do you mean by hiding events? What does this do?

[Pixelthief]

MMF2 reads through the event list from top to bottom each frame, calculating each event in turn.
When you execute a fast loop, it interrupts reading from the top to bottom and jumps back to the top and starts reading only those fast loop events from top to bottom. It repeats that once per loop
Events that are within closed event groups, "disabled", are not read at all. So if you place your fast loop code inside event groups, disable them, and enable them only when you invoke the fast loop, they will be read only by that fast loop.

When you run a fast loop it will still read through the events of other fast loop code in your project, because the only way it knows which ones to execute is based on matching the string, the loop name. Comparing the string itself has some processing time, but even greater is MMF2's overhead in just reading an event at all. If your event is hidden inside a disabled event group, its not read in the first place, so there is no extra processing time.

This is important because as the # of different fast loops in your project rises and # of times you execute a project is high, you have an exponentially increasing amount of processing. In big O notation, O(N^2) instead of O(N). Basically translating to mean that is a lot less optimized than it could be.