It is very strange that, in view of the current approach to the creation of objects, you can not use the factory as object pool.
It’s “must have” for any game engine. The implementation in the engine architecture is not difficult, i think.
And in the editor, it can be presented as a checkbox "objects pooling " and two fields ‘minimum cache size’ and ‘maximum cache size’
It can greatly increase productivity out of the box, reducing the load on the gc.
I’m not sure I understand what you, as a user, wants to gain from this object pool facility in factories. In the architecture, Defold consists of a number of “object pools”. We never allocate memory dynamically at runtime. Everything is very precisely allocated up front, acquiring a number of arrays with similar access patterns to make the CPU caches as happy as possible. You can think of this as the opposite of OOP and inheritance, it’s often referred to as data-oriented design. The good news is that this makes the cost of spawning game objects approach the cost of spawning particles, it’s really cheap. You control the “cache sizes” by setting different values in the game.project file, e.g. sprite > max_count. That value will define how large array we will allocate (once, when the engine fires up) for sprites. When you create/destroy game objects containing sprites, you will automatically get slots in these arrays, without needing to care. There is no GC happening in Defold at runtime, with the exception of:
Lua. Defold does not do any lua below the user level, it’s only user scripts who use it. The Lua GC cost is more related to what your update() functions do, than the cost of creating/destroying script instances.
Ref-counting for resources, e.g. textures. This is not really GC and doesn’t have a big cost, but related.
3rd party libraries, e.g physics engines. They typically have custom memory allocators to allow for OOP’y allocation (“new”) without paying the cost of general purpose dynamic allocation.
Have you seen any large cost associated with creating/destroying game objects? If so, it’s something we really need to look at, as it’s been designed to get rid of these costs.
Hmm, or are you interested in having all the spawned objects be automatically deleted when the game object containing the originating factory is deleted? Like ownership?
Oh!!! Thank you for the reply!
It looks like we have a great misunderstanding here. I’ve thought that any object is created dinamically.
Can you please add this explanation to manuals? Because first thing i’m currently doing is a creation of a pool for bullets, sparks, etc. (i came to Defold from AS3)
Yes, great idea! @sicher could you do this? I just asked @britzl to modify his crazy bunny demo to do dynamic spawning/despawning, so now we can put my explanation to the test! He will probably post numbers soon.
I really don’t remember some information like this somewere in documentation (but I read it all)
On forum I found only one place when you give advice to use tabels for object pooling Object pooling example?
Then this is what happens when you apply classic OOP on it, with a base class Node, virtual update functions, etc. The trace means function-calls on the CPU. Notice how the trace grows with the number of instances.
It’s a Data Locality http://gameprogrammingpatterns.com/data-locality.html - cool!
As I understand you already has all components and empty entities. And when object created you just set component links to entity - just a simplification of course .
But i don’t understand your advice in old forum topic.
The old advice was unfortunate, I thought it had to do with the particular game design in that case and not performance, as there is no need for lua object pools for perf reasons. I’ll update that post to reflect this.
In your architecture used all that I really love =) (Data Locality, ECS, and without thoughtless worship to OOP =)) )
And now I like Defold even more!
Thanks for your explanations.
I hope this topic help other users to understand how engine works.