Wow Pixelthief,Originally Posted by Pixelthief
That is a really great article.
Not sure why I never seen it before, but i'm glad I see it now.
Thanx
Wow Pixelthief,
That is a really great article.
Not sure why I never seen it before, but i'm glad I see it now.
Thanx
What scares me is that I wrote that *before* taking most of my CSci classes and graduating as a software engineer and all that jazz. Its probably not up to my professional standards of "2 years later" :S
but yeah, you can greatly speed up the efficiency of your fast loops in your program by arranging them into the "loop groups" I described in there. Idea being, each time MMF2 reads a fast loop, it searchs through every single code bearing a "fast loop" event in your code, and compares the string on each one (Although I'm pretty sure it does short circuit evaluation so its just one string comparison per event per loop, but thats still ridiculous overhead). Its a heck of a lot less efficient than a JMP loop in machine code, but without it string comparisons in the fast loop field would not be possible (but uh, how many people actually USE this feature- which is why I believe there should be a "faster loop" possible with preset loop values). But only the code that is in activated event groups is visible to the program, so if you make sure that all the other fast loop code in your event editor is locked out for each loop, it will only be parsing the minimum amount.
Question about that fast loop group.
So, when you do "[conditions] = Open group 'loop' + start loop 'fast' # times + Close group 'loop'" Does this mean any conditions that use the "on loop" function need to be inside the group called loop? Is that what this is doing?
The game I am working on has groups. However, the conditions that start the fast loop, & the on loop conditions are inside the same group. So do I need to Add another group for the 'on loop' conditions inside this group to be able to work this method correctly?
That sounds correct, yes. You can do nested groups-within-groups, so its really not an issue. For example, my code looks like this:
And my event group looks like this:
Remember to make your groups deactivated at the start, too! If you don't, the game will run slowly until its run each loop once. Anyways, the general idea here is to use the ability of MMF2's stack to return to the previously opened line of code while storing its stack frame.
When you run the "open event group", it modifies the global event list. When it runs the fast loop, it "pauses" that line of code on the stack- when the fast loop is finished, it will return to where it was, and then read off the "close event group" line. So as long as you do this, your loop does not have to have a terminator that closes its event group, because the stacked event on the calling line of code does it automatically
So wait, sorry to bump into this conversation, but how does putting loops into groups speed up the fast loop process, I am only using two loops, sorry, I didn't really read the article yet, I don't have the time at the moment.
-Thanks, Variant
So how does this making fast loops into its own groups faster? Not only does the condition starts the fast loop then checks for any 'on loop' conditions during the process, but now the condition asks to open the group and then close the group.
So if any group is closed, i guess the game pretty much ignores them? Although aren't any uncalled fast loops get skipped/ignored until they're called anyway?
When you run a fast loop, lets say loop index "Happy", it will parse through every "on loop" event in your entire code, and compare the loop index string. So it won't simply be reading the event for loop "Happy", but also for loop "Sad", "Melancholy", etc, every single loop event in your entire code.
If you have 1 fast loop in your code, it would make no difference. If you had 50 different fast loops, then every time you run 1 fast loop, it would be parsing 50x as much code as it has to.
So no- uncalled fast loops aren't ignored. Every "Fast Loop" function calls every "Fast Loop" event, and then compares the string in its index. But before you think this is awful- consider this: How could it be any different? Fast loop indexes allow you to have variable strings in the fast loop name. Most of your loops might say
On Loop "Happy"
But if you wanted it to, it could say:
On Loop (Global String A)
Up until the engine "reads" each event, it has no way of knowing if it will be a matching fast loop. This could theoretically have been implemented differently by clickteam if they had introduced a form of looping with preset indexes- so it always knew which lines to call, akin to a "JMP" in machine code. But that doesn't exist. So for now, by taking this precaution, you cut down on the amount of overhead each loop has by an exponential factor. If you have X fast loop lines of code and Y lines of code that each call a loop Z number of times, it would have to read X * Y * Z lines of code. By avoiding this, you make the time complexity linear for each line of code, reducing the total to Y * Z; this avoids a polynomial time (ie, this makes it much faster!)
Oh, it's a great concept, I may try it. However, each one of my fast loops (one per trigger) are triggered by different events, so I don't think that in this case this concept will help me, but it will help me in the future. Thanks!
-Variant
it will help you in any case in which you have a fast loop running which is not using code from other fast loops. Even if you only have one fast loop per trigger and different events, it will impact your performance.
However, until you get *lots* of loops in your code it won't matter. Its more a concern for large projects with complex algorithms that need many iterations. For example my 3D engine would use thousands of loop iterations per frame- and across maybe 30+ different loop triggers, this cut down processing time by roughly 29/30
Yeah, what I am doing is simple. Really simple. So I'll be fine for now.
-Variant
Posting Permissions
Reply With Quote
