Optimization Tip Compilation: Post Your Tips

How do I...?
1

Tip: End Complex Conditions Early

I didn’t really find any threads or informations on this, so I though this might be worth pointing out.

HDog’s performance took a noticeable dip after the last alpha update. I tried some stuff and it looked like events where the main offender. (Changing all assets to not be loaded in memory didn’t do much for example). At some point you might need a lot of complex events to control complex stuff all the time and HDog has that in the form of all the enemy behaviours.
Example one shows the fighter AI events that put noticeable stress one the system. But wait, example two is for another enemy that simply never existed during the test run. So all this events grouped under “hostile gunship behaviour” still run in the background and stress the system. Example three fixes this by checking first if the object that the group deals with exists at all. Example one could probably also be made less stressing by putting the easy, often false conditions into a parent event.
Maybe this is helpful for people dealing with performance issues in projects with a lot of complex events running at all times. :slight_smile: :question:

2

Personnaly i always limit loop and condition. A condition only if it’s related events are created previously, and for AI, that could use a lot of ms in the render when there a lot of ennemy, it triggers only on a distance conditon in a “for each” condition.
Each object that is supposed to act on screen is disabled when it’s 1500px out of the screen.

I always cheeck the performance monitor and my aim on the game is to keep the render time of the scene under 20ms in any case.
A little tips, but potentially great with impact if you have a lot of code : add “do once” everywhere it’s possible. On my first big project 3 years ago, i’ve saved 80% of performance with it : it’s not needed to process the same action at every frame.

Last tips : variable display (UI) refreshing : fast changing values (text/number) with multiple text objects on screen can have a big impact on perf. I figured out that it doesn’t need to be refresh at everyframe, and not all at the same time, so i use a chronometer (or better custom chrono with TimeDelta()), and all the refresh of the text objects are at different tempo : one is trigger at 0.25sec, the second at 0.5, the third at 0.75, etc. and then the i restart the chrono. I saved a lot of performance using this tips.

2 Likes
3

Nice! That was super helpful to read, if you got more advice I’d love to hear it. (Changed the thread to serve as an optimization tip compilations, maybe others can tune in too)

Right, this gets difficult if you need to apply the action to multiple objects that might meet the condition simultaneously. For individual objects I switched to states that get changed first as the action ins applied, that essentially acts as a “do once for each object”, but requires and additional albeit cheap condition.

Would be interesting to see here how stressing changing a variable continuously is by itself, since that could also be striped down to your chronometer system for each and every variable in game. Question is whether “pick every” for all the stuff you might want to updates its variables might be stressing again.

Also another question: From your experience, what are the most stressing conditions and actions the event editor uses?

4

There are lots of these sort of tips from ddabrahim in this thread: How to solve lag - #9 by kalel

5

It depends on a lot of things, but basically it’s really chronometers : i don’t use anymore actions and conditions related to this, i only use TimeDelta() custom chronometer, wich is really lighter. I also avoid to use mutliple chronos, sometimes you have to create one for each objects when it’s AI related, but for some case, a global chromometer is enough for multiples things (refreshing UI for example).
Refreshing text is really stressfull if you have a lot of values : it’s not always related to the game, but i use a custom “debug feature” in my projects to display every parameters of objects in realtime, and it’s really stressful if you have a lot of objects, so it’s needed to limit text refresh.

There is no action really stressfull, it always depends on the numbers of objects affected, and the complexity of the script. I really often make stress test : for example, i spawn 400 enemy entities and look how does it react ; i check in realtime each loops and group of events, and i try to reduce it to the maximum with the tips i given previously.
The most consuming things that i saw is using a lot of concatenations in variables conditions, used in sub event, sub event, sub event in a “for each” main loop, but there is nothing you can do on it. I’m also a bit “mad” with it since i use it a bit like SQL with tons of structures variables :smiley:

Performance on events is something, but you should also take a look on global ms for the display render (and fps of the game wich can drop sometimes) : using particules extensions for explosions for examples can create fps drop (with too much particles/objects created). Optimize your images, for both sprites/mosaic/particles, don’t use png and transparency when it’s not needed, optimize your png with tools like Tinypng to reduce the file weight (and destroy useless pixels information that even photoshop/gimp keep : transsparent pixel aren’t deleted, they just have maximum alpha channel value set).

Also, and last tips, i always chase for undeleted object : sometimes and i’ve never figured how/why, some object that should be destroyed aren’t (for example you destroy an ennemy, destruction generated 3/4 objects (explosions/lights/etc.) or even your projectile). In the order of event, it should be destroyed, but not… it’s often related to particule objects, and even if you have picked “self destruction” of the object when the capacity number of particles is over … For it, the only solution is to check the debugger objects list, and after try different order/sub order for the events.

I hope this will be helpful. For now my projects are sleeping because of the bug i’ve spotted few months ago. I always have memory leak problem in IDE preview, and it’s related to external events… i’m waiting for new Gdevelop version to support native games.

1 Like
6

Yeah I use global obliterate events between enemy waves, as far as I can tell those catch everything, with most objects having self-destruct conditions already beforehand.

With chronometers you mean timers thne? Is till use those a lot… good to know that they should be better stripped down. Do you know if pausing unused timers does help?

I have that too, but the compiled games seem to be unaffected. GDev also crashes a lot if I preview stuff after making changes to large event sheets, I got around that by almost always working in a small sandbox sheet now.

Most certainly, thanks a lot!

7

Yes timers sorry ^^ idk for pausing timer, but i suppose yes.

Ha ? Good to know i’m not the only one, also i’m working with 4.0.92 only, the 94 was too buggy and also have the bug. Did you reported it yet ?

8

I’m on 4.0.92 too. The preview lag was mentioned in the forum somewhere, so I assumed its a known issue. If I reported it then that was months ago…

9

Thanks for your tips again, you helped me optimize the game quite a bit. Another thing, kind of arbitrary but I didn’t think of it immediately: If your project gets really huge with lots of event sheets that all need to compile when editing a parent scene then you might want a way to deactivate sheets while making many subsequent edits (to cut down internal compilation time). There is no way to deactivate individual sheets, you can however cut and paste them into an empty “tray” project for storage, to be integrated again later when you need to compile the whole game.

10

:wink: TY ; impatient for the final realease of your game !

I’m not sure to understand your last tips, it’s to reduce the compilation time, or/and in preview ? If yes, what i do is cloning copy/pasting groups of events containing the whole external event sheet : event sheet cannt be disabled, but group of events can !

My project is in pause since June and memory leak bug in 4.0.92 :frowning:, i really hope the V5 will be available soon.

11

Yeah the last tip was concerning internal compilation time for previews, the stuff GDev does whenever you change something in your scene event editor. When changing something in the main scene that clocks in at ~400s, started to slow the whole project down in phases where there is stuff you need to preview a lot. I tried disabling large portions of the event or entire event sheets, but for me that made no noticeable difference, I assumed GDev always compiles everything for internal compilation. Putting your event sheets into another tray project temporarily gets around that.

How does your memory leak problem manifests itself? I’m still not sure whether the engine is really safe and sound when running for a long time, but I kind of got around this by destroying and relaunching the main scene whenever player start a new run. Or at least I hope so. For a long time I didn’t realize that GDev actually keeps your started scenes loaded if you don’t tell it explicitly to destroy them, that led to massive memory leaks for some time. I’m still not sure if I have really resolved this, I wish there was a “relaunch the game” event action that absolutely destroys everything…

12

The problem manifested by itself with the project growing in events and assets.
I tried to delete assets but it’s not the point (on scene nor in banks), it’s really linked to events and external events, wich are really needed if you want to change scene and avoid code duplication.

It’s clear that changing the scene and destroy the previous one is the aim to clean up the memory, so it’s impossible to avoid scene change… and duplicating groups of events is not an option, there are too many of them first, and secondly a fressh scene with couple of layers are the basis of all my different level designs and game engine design.
On another project, a complex one, with procedural generated level on an unique scene, i’ve written a little “auto mode”, and already successfully having the compiled executable it running for more than 24 hours without crash or performance issue, so game built on native GD engine might not suffer from memory leak on my experience. In “auto mode”, the scene realoaded about every 4 minutes (in a kind like of FTL game rogue like game). I’ve never experienced memory leak on preview in IDE too, but the game was developped mainly on GD3 and early GD4 versions.

I’ve wrote a PM to 4ian about his idea of GD 4.0.95 version to correct these problem, hoping he would be able to provide a solution to this issue… he suggested it in the topic about Gdevelop 5 development :

source : [url]GDevelop 5 - Version beta du nouvel éditeur - #18 by 4ian]

Translation : he’ll try to take the time for a new 4.0.95 version in his planning… // wich is quite overbooked with new GD version and lil bub game.

I really hope he could “easily” fix it, because we can’t know when the native engine will be released on the new version of the IDE.

13

Thanks, that was again super helpful, good to know that one-scene set-ups should work on the long run, HDog pretty much handles it exactly like that.