GML Question regarding a pooling system

Hi everybody!! I have a question regarding the use of pooling systems. The idea behind a pooling system is to avoid the need of massively creating and destroying instances. For that we have to rely heavily on activation and deactivation of said instances. I’ve read that activating and deactivating instances in GML can lead to lag and poor performance. With that in mind is a pooling system more efficient or less efficient than simply creating and destroying instances?! I tried to benchmark both approaches this but since the deactivation and activation of the instances doesn’t occur instantly (but during the end of the step) I don’t know how I can compare the both. Needed some help!
 

Catastrophe

Member
I think you usually you end up pooling objects that are so simple you don't even need to deactivate them. Like if you're pooling bullets in a bullet hell, just mark their speed as 0 and shove them off screen.

In any case, you might find this interesting, scroll down to "findings", they're using deactivation

https://csanyk.com/2016/12/gms-instance-pooling-performance-optimization/
https://forum.yoyogames.com/index.p...-good-instance-pooling-demo.14872/#post-99686

That said, object pooling isn't the only method, this post was interesting

https://answers.unity.com/questions/1145980/how-to-improve-performance-with-10000s-of-gameobje.html
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
Each deactivate / activate call does through the entire object list, so you've got O(N) performance. I think that calls affecting multiple instances take basically the same time no matter how many objects are (de)activated, because object list traversal and condition checking has more steps than moving them from one list to another, so you could speed it up immensely if you could use a region-activation / deactivation method instead of (de)activating one instance at a time.

For deactivation, this is simple: move the objects to an offscreen region, then use instance_deactivate_region(). Activation is the tricky bit, though... how would you ensure you only activate 1 instance at a time? One idea could be storing the instances in a line, with coordinates changing by 1 per instance, and then activate a region of size proportional to how many new instances you need from the end of the line. Basically, you have a physical stack of inactive instances. When deactivating instances, you'd move them to the end of the stack first, then deactivate an appropriately-sized region. There's a bunch of caveats here (Are the coordinates of the activation region inclusive or exclusive? Does the region take sprite/mask overlaps into account or only coordinates of the origin? How to efficiently move objects to/from stack coords) but if you can work those out this has the advantage of being conceptually simple.
 
Top