- Clickteam fusuion vs clickteam fusion developer code#
- Clickteam fusuion vs clickteam fusion developer download#
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). 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.
The issue is present for COLLISION detection in other common activation/deactivation setups too. I made some more tests and have some very interesting results.
Clickteam fusuion vs clickteam fusion developer download#
Vol! Your finding can be clearly confirmed! I made a stress test with 10.000 bouncing balls, you can download it here: 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.
Clickteam fusuion vs clickteam fusion developer code#
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. 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. The FPS results here were effectively the same as scenario 2.
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. 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!!) In both cases, the collisions were disabled effectively, but only in the first scenario was there any noticeable increase in framerate. In one scenario, I deactivated the events in the editor, while in the other scenario, I did it at run-time via keypress. The collisions were for various objects, but those little grey pebbles were the most relevant in this case. Have a look at the following:Īs you can see, in both scenarios, I deactivated two groups that had collision events in them. It appears that the processing for collisions continues even when you deactivate the code at runtime. I've just discovered something interesting. I tought I/you/we could take advantage of it Since you already have a test case going, Sorry for asking to try this couple things, hope not to bother, a cloned object B with shader applied in the frame editor object A (rightdir cloud) without shader applied I'm now wondering if/how much "applying" the shader in edit-time could change thingsĬould you try your original test 1 having two sets of objects: Just to look shader process vs non-shader during screen drawĪnd seeing how much the drop is without the bulky "shader application" part) (so not destroying them but having them lie onscreen, I wonder if this is the main cause of the slowdown in test1, and not the shader processing itself?Ĭan I ask you how much of a slowdown you get by:Ĭreating xxx dust clouds and applying the shaderĬreating xxx dust clouds without applying shaderīut checking framerates after them all have been created? (remember having mistakenly applied "always" a shader and hanging the game )īut since you are creating multiple objects and applying the shader to them on the fly, I had noticed applying shader in runtime is quite expensive
0 kommentar(er)
