What is the point of this? To run a fastloop inside the same evnt? Please be more specific, I don't understand.
What is the point of this? To run a fastloop inside the same evnt? Please be more specific, I don't understand.
Working as fast as I can on Fusion 3
It's fairly simple in theory:
It would force MMF into going back up and repeating actions it has already done (within the same event). The result would be a new kind of fastloop, but potentially a LOT quicker.
Fastloops would always have their place, of course, because these loops wouldn't be able to update their own conditions (so you couldn't get it to stop on certain conditions, or even test for them without using Immediate If).
However, if there's a variable inside MMF that actually holds the ID of the current event being processed, rather than just the action, then potentially a version could be made that derailed the event parser and rerailed it back to an event it had already handled, kidding it into handling it again. That would give you conditions, whilst possibly losing the slowdown you apparently get thanks to 'trigger'.
The real advantage is just speed, at the end of the day. Could be great for reading files.
I see no difference in this and just adding the same conditions that triggered the fastloop. Seems pointless to me. :p
Working as fast as I can on Fusion 3
It doesn't seem pointless to me, but it seems useles... at least for my needs...
How can it possibly seem pointless? It's a faster fastloop, that's all it is.
Handling conditions, and the whole 'trigger' process, all take time that many apps don't have. This technique, if it's possible, would completely avoid that problem. It would have the same effect as copy-pasting the same actions inside an event, but has the advantages that you only need to update one copy in the event of a bug, it'd be easier to display in the event editor, and of course the number of iterations could be determined by expression.
The main uses I'm thinking of are drawing pictures and loading files, and processing procedural data inside objects (any kind of process that needs multiple iterations but not complex conditions). Within reason, IIF Object could help with some basic conditions too.
I see what you mean Dines and if this worked... it would probably be faster than fast loops...
I hope someone tries this out!
This isn't pointless at all.
But i would love to see it taken a bit further, many programs have the core of there most tightly run loops in assembly and call on the thou a higher level language... maybe an extension such as the pipe object (for bat files) but instead running assembly scripts?
i'd love to see if this helps the communication bottleneck between lua+ and MMF, either alone can run pretty fast but they trip over each other if you need both
currently the only two ways i can think of getting an OO engine in lua to "sync" with the objects in MMF are:
1. run a For loop inside lua for as many objects are in the table, then call a function in MMF that contains the variables and fixed value of the object to update (what i'm doing now... starts lagging like hell if there are more than 200 or so "active" objects to update)
2. run an ID fastloop for each object in MMF, send its fixed value to lua, then return all the object's variables to MMF and apply them to the object (haven't tried this yet, and i don't expect it to be faster; in fact it may be slower)
both of those methods involve an immediate condition, so i'd be interested in seeing if this would manage to support more objects (probably not, but it couldn't hurt to try it)
This is a great idea. An example would be:
On condition:
--- LOOP (X Times) ---
-Edit Box: Set Text to Edittext$("Edit Box") + Y
--- END LOOP ---
In one event, we just appended string "Y" to an Edit Box "X" number of times. Fast loops would require 2 events.
Yeah, and of course if you named the loops, you could have nested loops.
Just depends if anyone's had any success with this. Has anyone managed to try it yet?
Posting Permissions
Reply With Quote