The Clickteam Fusion 2.5 optimisation & performance Hard Data thread

[schrodinger]

Interesting,
I had noticed applying shader in runtime is quite expensive
(remember having mistakenly applied "always" a shader and hanging the game )
but since you are creating multiple objects and applying the shader to them on the fly,
I wonder if this is the main cause of the slowdown in test1, and not the shader processing itself?

Can I ask you how much of a slowdown you get by:

creating xxx dust clouds and applying the shader
vs
creating xxx dust clouds without applying shader

but checking framerates after them all have been created?

(so not destroying them but having them lie onscreen,
just to look shader process vs non-shader during screen draw
and seeing how much the drop is without the bulky "shader application" part)


Also,
I'm now wondering if/how much "applying" the shader in edit-time could change things

Could you try your original test 1 having two sets of objects:
-object A (rightdir cloud) without shader applied
-a cloned object B with shader applied in the frame editor


Sorry for asking to try this couple things, hope not to bother,
since you already have a test case going,
I tought I/you/we could take advantage of it

[Julian82]

Thanks for the research on shaders, very useful! I also realized that setting shaders on runtime to individual objects can be extremely expensive. I usually shift objects that need aleration to specific shader layers, so the shader is preset in the layer, which seems to be much better performance wise, but I never tested in detail. A layer with a shader that has not one rendered object in in also does not seem to affect performance at all, as Fusion seems to skip those layers when rendering. However when the first object is shifted it costs performance but it seems as if it does not matter how many objects are shifted to a shader layer. Of course this approach is not suitable for all situations and shader types.

[Volnaiskra]

Can I ask you how much of a slowdown you get by:

creating xxx dust clouds and applying the shader
vs
creating xxx dust clouds without applying shader

but checking framerates after them all have been created?

No dust clouds on screen:........................................... .........................99fps
5000 dust clouds on screen, no shader:........................................... .......50fps
5000 dust clouds on screen, flip horizontally shader previously applied:.......24fps

I'm now wondering if/how much "applying" the shader in edit-time could change things

Could you try your original test 1 having two sets of objects:
-object A (rightdir cloud) without shader applied
-a cloned object B with shader applied in the frame editor

I thought that setting the shader at edit time instead of runtime would make a positive impact. But according to 3 test runs I just did, it makes absolutely no difference - same result each time.


@Julian: Interesting. I'll look into layer-based shaders when I get the chance. I can imagine utilising this technique myself!

[Volnaiskra]

I've just discovered something interesting. It appears that the processing for collisions continues even when you deactivate the code at runtime. Have a look at the following:



As you can see, in both scenarios, I deactivated two groups that had collision events in them. The collisions were for various objects, but those little grey pebbles were the most relevant in this case. In one scenario, I deactivated the events in the editor, while in the other scenario, I did it at run-time via keypress. In both cases, the collisions were disabled effectively, but only in the first scenario was there any noticeable increase in framerate. And it was a pretty huge increase at that - 50% FPS increase when moving! (there were an awful lot of those little pebbles in the scene - turns out those silly little pebbles were probably the single-most expensive thing in my entire game - pretty crazy considering they are a subtle piece of eyecandy that many players wouldn't even notice!!)

Not pictured is a third scenario, where I uncheck "active when frame starts" on both of those groups: so the code still exists in the runtime, but it is not active at any time. The FPS results here were effectively the same as scenario 2.

The only conclusion that I can make from this is that Fusion continues to check for collisions for any object that has collision code attached to it - whether or not that code is active or not. So, even when I disable the code in-game (or by unchecking "active when frame starts" in editor), Fusion still tests for collisions for every one of those pebbles each frame, even though it doesn't actually do anything to them when it does detect a collision.

This almost feels like a bug to me, but I get the feeling that if I reported it, Yves would say that it was impossible to change, or that there's actually a good purpose for it which I wasn't aware of.

[Julian82]

The only conclusion that I can make from this is that Fusion continues to check for collisions for any object that has collision code attached to it - whether or not that code is active or not. So, even when I disable the code in-game (or by unchecking "active when frame starts" in editor), Fusion still tests for collisions for every one of those pebbles each frame, even though it doesn't actually do anything to them when it does detect a collision.

This almost feels like a bug to me, but I get the feeling that if I reported it, Yves would say that it was impossible to change, or that there's actually a good purpose for it which I wasn't aware of.

Holy ****! I'll build another setup to test this too. If this can be confirmed, it is surely worth a bug report. Even more important it would fundamentally change the way you've to structure code for performance optimisation.

[Julian82]

Vol! Your finding can be clearly confirmed! I made a stress test with 10.000 bouncing balls, you can download it here: https://www.dropbox.com/sh/8tc1gl7q4...Sg_vdx68a?dl=0

I made some more tests and have some very interesting results.

The issue is present for COLLISION detection in other common activation/deactivation setups too. I made another test and tried to deactivate collision detection by putting a global value (1 = check, 0 = don't check) on top of the collision check condition. It made no difference!!

RESULT: COLLISIONS are always checked, no matter in what position the condition line is (Fusion does not skip the condition block on the first false line if there's a collision detection in it!) and no matter if it`s in a group that got deactivated on runtime (but was active when starting the game).

However, this is NOT true for OVERLAP detection. Overlap detection is chancelled as expected in both the group deactivation and the flag setup, resulting a massive framerate gain in my test .mfa (it goes up from 30 FPS to 350 on my i3)

RESULT: Overlap checks can be deactivated within their groups as well as by using flags, Collision detection can not.

[Julian82]

Another finding: Collision conditions are even checked inside Fastloops that don't run :/ This is really crazy...

[Julian82]

Two more findings:

x Collision detection is run even if an object is out of scope (by flag)
x Collision detection is done for every object even if the detection condition is run in a for each loop and this object is NOT included in the loop

CONCLUSION: COLLISION detection conditions seems to be done ALWAYS, no matter what you do. Only the subsequent event execution is scoped. Detection checks cannot be deactived by groups and are even run if the objects are out of scope or included in fastloops that are not even run. This is clearly odd and I personally will only use OVERLAP detection in the future, as this can be scoped and deactivated as expected. Too bad some few things oly work right with collision detection :/

My attached .mfa shows proof of Volnaiskra's and all further findings.

[Yves]

It's not crazy, collision management is complex.

When a frame starts, for each object Fusion builds a list of objects that are involved with it in "on collide" events. This list is used for triggering "on collide" events and is used when an object moves or is animated. Updating all those lists and re-scaning all the events each time you start a loop or activate a group could take some time or is difficult for a reason I don't know. It's probably not a change you're going to see in Fusion 2 unless I can find a free week (which is not going to happen...) and can check how this works in detail & try to improve it.

This doesn't happen with "Is overlapping" events because collisions in those events are tested when the event is treated.

[Julian82]

Thanks for the explanation Yves, really appreciated ^^ and very good to know!