Is object pooling convenient for construct 3?

I am making a bullet hell game and i made an object pooling system and once the bullets get outside of the screen they get disabled and stop moving. To enable the bullets i use a bulletSpawn function which picks random disabled bullets and sets the position, speed, move angle, etc. unfortunately, i stumbled with a big problem, the game is unable to go above 60 fps with more than 400 bullets even if they are disabled, the game literally ran better by creating/destroying objects. So i wondered, is my object pooling system not well programed or do i even need to make one?

If there's no object, then there's nothing to keep track of, and nothing to render.

The engine is well optimized to work with creating, and destroying objects as you need them as long as you remember to design around the fact that objects don't fully exist until the next tick, and that garbage collection is not a controlled process.

I see now, thanks for your response!

just curious why you'd ever want your game to go above 60fps

just curious why you'd ever want your game to go above 60fps

I have a 240hz montior. Sadly not because my PC is strong enough to support it (unless the games are older) but simply because my old one died and this one was on sale :V My Laptop also has 144hz. Construct games run tied to the monitors refresh rate, so as long as the PC can handle it the game WILL go above 60fps naturally. I'd be quite sad if a game doesn't reach 144hz on my 144hz monitor, especially if it isn't 3D maxed-out eye-candy.

To be fair, my own game also runs at around "only" ~150fps though considering the 2D nature it probably should be more. I just noticed... it does run at 240 in the preview but not in the export. Hmm...

In any case, the faster the game runs the better. If it hits 240fps on your machine it might just hit 60 on an older one. But if it already is chugging along at 60 on yours, the older one might hit 10 fps and it's unplayable.