I am currently running into a performance problem where I am using the fire bullets extension to spawn and apply a direction for a projectile. The projectile is a spiked ball. It fires a projectile every one second at a position off screen for five seconds. Once the projectile is off screen, it is removed. After two to three iterations of this, I start to get noticable frame drops. Where I believe the performance loss lies is that I am also rotating the spiked ball via events. I know it’s not ideal versus animating the rotation, but could the performance loss be that great?
Hi, since you are using an extension, I doubt the rotating is the problem.
Could you screenshot the events of the bullet? It may help.
Hello reina,
Thank you for your reply!
The spiked balls also have the behavior applied, that once they are off screen, they will be destroyed.
I have attached a screenshot of the events in this post. (Happy New Year)
Thanks, happy new year to you too!
Yep, this looks fine actually. I think it’s the bullets not being destroyed properly, or that there are too many on screen.
If you still need suggestions, I guess you can screenshot the bullet code next? 
Or I hope you figured it out…
Hi,
I actually don’t want to dissent with reina (edit: reina is right though, the events work), but I think your events don’t look fine at all. The problem is the inflationary use of wait-actions. Particularly their use together with the fire bullet behavior is absolutely unnecessary. The behavior allows you to set a cooldown rate (Firing cooldown) and the amount of bullets you can shoot (Max ammo; Starting ammo).
I would also get rid of the wait-action for your show layer-action and use a timer instead.
I don’t know if reducing the wait-actions is improving your performance (I wouldn’t be surprised though if that was the case), but to get a better idea where the problem is you can use the performance profiler: Profile your game - GDevelop documentation
I think reina is correct on why you are getting the performance issue.
It doesn’t look like you remove the spike balls at any point, you just keep sending more. This means more and more of them are being loaded into memory every time it’s launched. Eventually you will run out of memory and hit a lag wall.
This is also known as a “memory leak”. Your game is allocating the memory for that spike ball object, but isn’t removing the object from memory when it leaves the screen.
Well, that’s what reaply wrote:
You can’t see that in the events because there is a ‘destroy outside of screen’- behavior which reaply is apparently using.
He may not be though. The basic description of his issue points to a memory leak. I want to make sure that there is something that is deleting the spike ball, or else that is his issue.
I can’t make the assumption that he is using the behaviour without seeing a screenshot of it.
As for the spiked ball not being deleted, here is a screenshot of the behavior applied to it. It should be getting removed once it is off screen. I have not actually reviewed if it’s happening, but I suppose I could create a variable to keep track of how many instances of the spiked ball are currently in the scene in real time. As for over using the wait actions, I am not sure of a better way to do this. I am using the FireBullet behavior to spawn these Giant Spiked Balls that will go across the screen that have to be dodged by the player, and I want specific quantities being used (hence the wait actions being used).
I just quickly rebuild your shooting events:
and even though I don’t like how they look, they work (and that’s the most important thing). I can trigger the events as much as I want without any change in performance. So whatever causes the problems for you it is not about spawning the bullets and rotating them.
I would recommend to use the debugger/profiler. Maybe you can find something unusual there.
1 Like
I know it’s not the most elegant, but as you said, if it works it works.
I did profile the game a bit, and I found that the renderer alone is taking up 39% while Admobile, using 38% was actually spamming warnings, Banner not configured, use setupBanner first. which I more than suspect as at least as a key reason. I identified the event causing the spam and I believe it’s helping increase the performance to a matter satisfactory expectation.
Thanks for the help everyone 
2 Likes