Optimization of a large project


There are a lot of errors on loading images of the main character.

You can fix those. Click on the project icon (top left in the editor), select Game Settings > Resources. Right click on the images and select “Remove resources with Invalid Path”.

The run the game again and check the errors no longer occur.

However, I don’t think this will solve you lag issues.

2 Likes

Optimization tip based on your code snippets:
If you have a lot of objects then doing a “For Each” can be expensive, but you can reduce that cost by doing all the “selectors” first since they are faster… so what I mean is

Instead of this:
For each Enemy

  • Enemy var detect = true
  • Enemy distance to Rose < 1500

Do This:
Enemy var detect = true
Enemy distance to Rose < 1500

  • For each Enemy

So basically the number of enemies looped over is filtered down first
Not sure it applies, but something that I used to optimize

5 Likes

Definitely a best practice habit to get into. It may not make any difference in this case, but in general it can have an positive impact on performance.

2 Likes

Thanks a lot! I still have a question. Will the judgement for each enemy’s variable be affected if it the event is not in ‘repeat-for-each’?

Yes, In GDevelop they call it “Object Picking”:
https://wiki.gdevelop.io/gdevelop5/events/object-picking

A top level event will evaluate against all of the named objects in the scene, subsequent conditions in the same block and all sub-events will be only against the objects picked so far.

1 Like

So does it mean that even if I don’t use repeat-for-each the variable of each enemy can still be judged correctly?

For most things, yes. So say position, object variables etc, then it can. But if you want linked objects, then a repeat-for-each-object will be required.

1 Like

OK! I’ll try this method.

I don’t believe the changes to selecting the enemy will make a difference to your lag issue. You identified that it occurred when the decorations were added. I think you’ll be better off focusing on that area.


I’d suggest using the perfomance profiler in the debugger to get a better picture of where the processing is allocated. The best way to identify is to add a number of event groups, and set a number of events as subevents off the event group.

In the profiler, it will break down the processing times for each event group. This should help identify where most of the processing is taking place

Here’s an example of what I mean. The event groups are the blue sections (I’d suggest not having one event group per event, but rather one event group for a number of events, or a group for an event which has a number of subevents) :


When I run the profiler :

image


I get :

Spot the event group names. Looking at the right hand column, I see that group 2 took over 1/3 of the processor time. This is where I’d look to make improvements (if it were a multi event group).

1 Like

Well, I’m having some problems with using the debugger. Every time I start a preview with it, it turns out to be not activated, even though I start it with the debugger button.

I’m new to gdevelop… you can’t just scale the level down to be one floor level that way the scene will only have to deal with a few items than dealing with a whole mutli floor one level… unless the game play require you too than is there away for you to not iterate over items if they not visible? cause anything out the scene of the drawing area shouldn’t be of concern unless you want it to be and than at that point it’ll be only a few items. your game look simple to me with just a bigger scene… if it using webgl to render than the performance impact has to be on your side… back track, go back to when it was working and than add stuff slowly while watching your performance… but again i’m new to gdevelop but i do hope a game of your scale isn’t the problem and you just had bad conditions and actions which lead to bad performance.

1 Like

Thanks a lot! Could you please tell me more about the floor and level part?

I’m referring to the picture showing multiple floors in one scene, if the player doesn’t have to see those floors don’t have them render, separate them by a gdevelop way (I’m a beginner so like others have said, groups,layers,different scene) how ever to separate the floors to render when ever the player is on that floor, if you going to have the player be able to look at the other floors while being on another floor than have those floors that will need to be seen… i’m a beginner so I don’t know gdevelop well enough to give a good opinion like the others have… turn off what is causing the lag, look at how else you can do it, or just remove the part that causing the lag with a smart replacement instead of trying to maybe keep your code the same, object picking may be all you need for those lamps, allowing the engine it self to filter the current interacted object dealing with that current run conditions and actions.

if you find a solution please post it.

As a heads up, GDevelop already does object culling (no longer render their sprites/animations) once they are no longer in view.

You shouldn’t have to manually hide them as it won’t change performance.

I’ve been messaging with @HcXy and tested out the game. The lagging appears for me when the scene is run as preview from the editor. If the first scene (a menu scene) in the game is run and the offending scenes opened up from there via a change scene action, then there is no lag.

I’ve had similar experiences previewing external scenes from the editor, and wonder there is something in common.

so the lag appear when the scene is ran in preview mode form the editor? what you mean regarding the menu scene? are you saying that how you fix it with him by having change scene action… it sound like the preview may lag but not the build is what you are saying.

No.

The engine starts previews from whatever scene you’re currently viewing in the editor.

To rephrase what MrMen stated above:

  • If the preview is started from the normal (main menu) scene, there is no lag.
  • If the project is previewed from a different scene than the starting (main menu) scene, there is lag.

No clue why that would be (unless there’s a bunch of events relating to loading up logic in the main menu scene that is missing in the other scenes, which could cause issues).

1 Like

So when I preview the scene in the scene editor, the game lags a lot, but when I preview it in the event sheet of the scene or in any external events it doesn’t happen. It is the same for all playable scenes with decoration. However, for the latest two scenes, even though I start the preview in their event sheets they still lag. At least they are not as laggy as the scenes previewed in the scene editor.

1 Like

I’ve just discovered that if I run it in preview from the scene editor, it lags. But as soon as I click on the events tab (while the game is running in another window), the lag disappears. And if I view any scene while the game is running, it lags. But as soon as the editor is minimised or a non-scene tab is viewed, the lag disappears.

It’s as if the editor and game are both fighting for a shared display resource when they are both visible.

1 Like