, an idea about a faster, new type of loop, "For Each Pair". I got this idea when reading a thread about gravity simulation ( viewtopic.php?f=3&t=1627&st=0&sk=t&sd=a
) In gravitation calculations, you must loop trough every object pair, because every object casts a force to every object. Traditionally you would do this with nested for each loop, which is unfortunately really slow. The gravitation simulation uses a loop where every object is tested with every object. This is a very common special case of nested loop, and I think that it could be TWICE faster!
A nested loop. Numbers are object instances and I means that the looping event is tested with instances of it's column and row.
1 2 3 4 5
1 I I I I I
2 I I I I I
3 I I I I I
4 I I I I I
5 I I I I I
"For Each Pair" -loop. A new kind of loop which would perform about twice faster. O means that the looping event is not tested with the instances of it's column and row.
1 2 3 4 5
1 O I I I I
2 O O I I I
3 O O O I I
4 O O O O I
5 O O O O O
So, it runs through every PAIR of instances only one. I.e. if it has already tested and performed the event with instances 1 and 3, it won't do so again with instances 3 and 1. On top of that, it doesn't perform the loop with the instances 1 and 1, in other words, the same instance (well, this could be an optional choise). "For each pair" -loop could use "instance naming" described above.
[code:39e3huh9]For each pair of Asteroid (A and B)
>> Set global('TempForce') *force calc here*
>> Asteroid.A.[Physics].AddForce global('TempForce') towards Asteroid.B
>> Asteroid.B.[Physics].AddForce global('TempForce') towards Asteroid.A
In theory, an loop like this, when optimised propely, would be a little over twice (minus overhead) faster than a nested loop, because the operations are done for every object pair, instead of every object... It's impossible for me to say would it really be significantly faster in Construct if implemented, but it might be worth of testing.Finally
, some other picking thoughts... Does "Pick random" pick randomly from the current Selected Object List or from all objects? I experienced some difficulties with it when trying to get it pick from SOL. It SHOULD pick from SOL, shouldn't it? Also, "Pick n objects randomly" would be nice.
Then about forgetting SOLs... currently the function object is the only way to forget a SOL inside an event. I think that this is such a basic functionality that using Function object feels like a workaround... How about option of forgetting SOL in subevent? Or something like that.
Oh, one more: Did construct suppor arrays internally? (Haven't used them and I am on comp that doesn't have Construct now) If so, whould it be possible to save and load object selections to and from arrays? Would speed up and simplify certain things, and allow even easier debugging with selections issues.