I have 2 questions:-
.
1- How it matters how you arrange your events? because sometimes when I arrange some events in a specific order it works, some other times it doesn’t and I have to arrange them a bit, what’s going on? how does that work?
.
2- I use hide and show events a lot but what I’d like to ask is performance related, does it matter if the object in hidden or visible? also does it matter if the object is outside the screen hidden and when on screen it’s not? I’m asking because a couple of months back I noticed something.
I have these platforms that Miko walks on, but I noticed when they are hidden no lag happens but when they’re visible lag happens a lot, so I was wondering, how does that work? does Gd don’t render an image until it’s visible? if that’s the case can you use that to hide objects outside screen to increase performance?
Events occur every frame their condition is true, from top to bottom.
The first event in the sheet is evaluated, then the first condition of that event, then second condition of that event, etc. At that point, the first action is evaluated, then the second, etc.
Event, condition, and action order therefore matter VERY much. If you have an event that is supposed to move an object, but the object isn’t created until lower on the event sheet, you will have to wait a frame before it moves.
Whatsmore, if you have actions that are only supposed to affect the newly created object instance, but they’re above the creation action in the same event, they won’t be triggered on that instance at all, and may activate on another instance somewhere in the scene.
Hiding/showing only impacts performance in regards to memory as far as I know.
Since the events are still evaluating on that event every frame, CPU/GPU performance are not impacted. The same is true for objects not on the screen. You could set up conditions to have them not be evaluated based off show/hidden (first condition being “event is visible” EXPLICITLY checks for if it’s shown/hidden. It does not check for onscreen or not.)
@Silver-Streak thank you so much for the detailed response but I have another question:
What about external events?
Lets say you have a scene with 50 events … with a linked external event sheet with 100 events.
Case 1 : You put the linked external event at the bottom of the 50 events.
Case 2 : you put the linked external event at the top of the 50 events.
Which is better in this case and how Gd manage that?
.
Another question would be:
Is it better to have a linked external event with 400 events or … Have 4 external event with 100 events each? Does it matter?
.
Also is it better to use external events in general or using events directly on the scene is the better option? Which one loads faster? Does external events slows down loading which results in lag or stutter in-game?
The objects in GDevelop have two parts.
One is the graphics part, the other is the GDevelop part.
The graphic part is handle by PixiJS and this is used for render the object on screens.
The GDevelop part is used for compute the properties of the object. (Position, rotation, behaviors, …)
When you hide or when the object is offscreen Pixi will not render it.
But the GDevelop part is still active.
Because stopped the rendering of an object in these two parts will completely block its use in the next frames, and make it this objects non useable in the next events.
For example, if you have a timer or an events related to a propertie on your object and you hide it and the timer or the event is not longer computed you don’t want that. That’s why the GDevelop part continues.
If you want to pause this part, you can disable the behaviors of the object, there is an action for it.
When you hide an object you hide it that’s all, you don’t disable it, these are two different things.
For disable an object completely the better thing to do is to delete it.
Or disable the behaviors with an action.
See these recommendations.
(Should I add the details on these two part of an object in this page?)
About the External events:
In your main eventsheet where you add the link to your external events, consider that all the content of this external event will be added exactly where is the Link in your main eventsheet.
Add external link on top or at bottom of the main eventsheet have an interest only if the order of your events are important like Silver has explain:
It’s the same duration to process in game for players because the event are converted to Javascript during the export.
For the creator use external events can be a bit longer of few ms because the engine have to pick the event somewhere else than in the event sheet of scenes.
This mean use external events affect only the export of few ms.
The explications here are very good already but here is an event optimization example I like to show around to complement them:
This is unoptimzed:
This is optimized:
The main difference here to take into account is object selection and complexity (time it takes to execute). Collisions checks use some heavy math multiplied by the amount of hitboxes so they are very complex, and conditions/actions that use objects are used on all selected instance of an object, meaning its complexity is multiplied by the number of instances of the object. So as you can guess, an object collision test (big base complexity multiplied by many instances) is very bad for performance. On the other hand, trigger once and click pressed pretty much just check one value with another, it’s about as non performance taking as it can get.
The other thing to consider is that GDevelop doesn’t continue executing if one condition was false. So on the first unoptimized example, we begin with the very performance taking condition, meaning no matter what it will be executed every frame 
Only then do we check for click and trigger once, which are the lighter conditions.
The second example checks the lightweight click condition first, so that’ll be the one that will be checked every frame. Then, if it does get pressed, it will trigger once, so that the collision will be done only when I first press click and not while I click. I could put the trigger once after but that would result in far more heavy collisions checks to be executed, every frame I keep the mouse pressed. With that optimized order, I make sure the heavier conditions are only called once.
Similarly, not using sub events can cause bad performance as well. For example see this event from the platformer template:
This is a very bad idea as we are doing many collisions tests every frame. We can invert the condition orders like this:
But we can do even better by putting all the events as a subevent like this:
That way the condition “mouse pressed” is called only once, and not multiple times. Sure, those actions are very lightweight, so calling them more than once isn’t that bad but stuff like this can accumulate and cause more serious issues on massive projects (like yours
).
I recommend taking as habit to take time to think about what events you can merge and what conditions are heavy and should be called last, to make more readable and optimized code.
@Bouh Thank you so much for the detailed explanation, that probably was the best explanation about this matter, I understand now how this works.
@arthuro555 My god you’re amazing man, I’m sorry for the late reply but I was so busy testing what you said about rearranging events and I did that in Puffball and my goodness this optimization technique is just pure magic, I had micro stutters in some areas in the game and in other levels it was heavier, so I just sat down and stopped everything I was doing in the game, and after 12 hours of testing.
in some levels I got from (8 ms) to (3 or even 2 ms) and yes there is still so little to no micro stutter left but it’s absolutely very playable now than before.
And this helped me to even make the loading time of levels from (2 seconds) to (1 seconds) which is crazy good with levels this big.
.
I can’t thank you enough man, thanks for the awesome help and explanation.