Fusion 2.5+ DLC Official pre and post-launch Thread

[casleziro]

Hmm...

I have a movement engine for multiple actives that I used to test. Both frames did the exact same thing: create 2000 moving actives that have basic backdrop collisions.

Frame 1 used the "standard" method I listed earlier, while frame 2 used mainly child events. An example of the differences in structure:

standard
standard.jpg

childs
childs.jpg


The standard method keeps a stable 60-61fps on my machine (the target framerate). The childs method only reaches 39-40fps. This might be related to childs and object scoping, since my movement engine relies heavily on fusion's auto scoping. I'll try to do more tests later. If anyone else could do similar tests I would appreciate it!

[Volnaiskra]

I did a test using VACCiNE 2's built-in benchmarker <---- shameless self-promotion. I thought I'd be using the new profiler for this sort of testing, but it doesn't seem to be set up for that. You can't seem to use it to easily measure specific chunks of code. Instead, it's more about measuring everything, and finding the bottlenecks wherever they may be (which is arguably a more useful function). Anyway, according to my test, which I ran several times in a couple of different iterations, the child method is consistently slower than the old method, just like your test suggests. In my particular test, though the difference is consistent across multiple tests, it's too small to really matter.



If child events are ignored by Fusion until the parent condition returns true (I don't know if this is true, but I certainly hope so - otherwise I don't really see the point of child events), then it's possible that the child event method would still speed up your game, despite the loops themselves running slower. That's because IIRC having lots of "on loop" events in your code has a very significant cost, because any time you run any fastloop, Fusion has to trawl through every event with an on loop condition to check if it's part of the desired loop. So if you greatly reduce the number of on loop events by using child events, then you may speed things up overall.

Then again, you can already reduce the on loop events without child events, just by hiding them inside groups that you activate/deactivate on demand. This is how I do most fastloops in my MFA. I was going to convert all my fastloops into child events, but seeing the performance tests, I think I'll just stick with the old group method.

So far, the child events have been one of my few disappointments with 2.5+. Their performance is questionable, and they don't seem to add much that wasn't already available with group-based pseudo-child-events, plus there's the generally clunky way they currently work:

-you can't collapse them
-there's no easy way to convert existing events to child events but instead you have to use right-click menus and create (and then delete) fake new events
-you can't use green conditions in them (even ones that you can successfully use in fastloops or deactivated groups)
-If you have a really long string of child events, the parent condition can go offscreen, leaving you looking at incomplete events, without any visual confirmation of what the parent conditions actually are.

Still, I don't want to sound too negative, as it doesn't personally bother me much. It's a single blemish in what is otherwise an absolute christmas basket of awesome features. 2.5+ still ranks as the best single software update I've ever personally experienced

[Yves]

Hmm...

I have a movement engine for multiple actives that I used to test. Both frames did the exact same thing: create 2000 moving actives that have basic backdrop collisions.

Frame 1 used the "standard" method I listed earlier, while frame 2 used mainly child events. An example of the differences in structure:

standard
standard.jpg

childs
childs.jpg


The standard method keeps a stable 60-61fps on my machine (the target framerate). The childs method only reaches 39-40fps. This might be related to childs and object scoping, since my movement engine relies heavily on fusion's auto scoping. I'll try to do more tests later. If anyone else could do similar tests I would appreciate it!

Do you have a MFA with both normal and child events I could profile here to see what happens?

[casleziro]

@Yves sure. I found the culprit while making the MFA; it was the collision foreach loop with using child events:

culprit.png

[Yves]

Hmm, I think I see... There have been several optimizations in On Each loops, one of these optimizations could have no effect in child events of On Each loops. I'll check to see if we can keep this optimization in this case.

[casleziro]

I appreciate you looking into this

[casleziro]

@Volnaiskra interesting results, thanks. I really need to use your benchmarker more often!

Wrapping loops up in their own groups is a habit I picked up a while back myself. I'm still fairly happy with how child events currently work regardless; I trust Clickteam to tweak them down the line since 2.5+ only just released.

[MrCyberpunk]

I don't want to sound too negative, as it doesn't personally bother me much. It's a single blemish in what is otherwise an absolute christmas basket of awesome features. 2.5+ still ranks as the best single software update I've ever personally experienced

This has been my impression as well. I'm just holding out on bugfixes before I give an endorsement. Its a very good step in the right direction but it needs polishing. still I'm sitting here on a 20FPS increase in performance out of box. (10 from the patch to 2.5 and 10 from the DLC DX11 mode). The fact that the object limit is 30000 now is AMAZING, the fact that there's a button for the Behaviours timeline view is a game changer, Child events are fantastic, the Profiler is great and its surprising to see the metrics it gives you. It is a very good addition. I like how much better everything runs in general.

Pretty much only thing to prevent me from openly endorsing it is compatibility issues. Some extensions are broken by the DLC and the shaders need porting. Once I get those though I'll give a pretty glowing endorsement because this engine is flying now.

[casleziro]

DX11 definitely offers a large performance increase over DX9, so it will be that much more powerful when all the debugging has finished. For a benchmark, I can get 6000 moving objects at full framerate on DX11 vs 2000 on DX9.

[Volnaiskra]

Though I could do without this thing that just started popping up on every launch. Er....I already have 2.5+, I already have the full version, and I already got it on Steam. Must I really be shown this popup each time?