I’m creating 100 or so background game objects with a factory, that I scroll in game. My gut tells me to cull the panes outside view, but when I do this the fps drops somewhat. When I remove the culling altogether it runs smoother, which is surprising to me.
I even maxed out the sprites and had 1000 factory created sprites, and, after a period of settling when the app starts, it runs smoothly without culling!
What’s the best way of culling game objects? Is it even needed? Teach me, Obi Wans!
Well I think you answered this question yourself already 
Defold preallocates memory for resources e.g. sprites, game objects etc. according to the settings in your game.project file and is designed with performance in mind. I guess culling would make sense if you have a lot of geometry or heavy scripts on each game object but it will depend from case to case.
As Johan said, you answered the question yourself. My tip is to not optimize before you know if it is necessary. Use the profile to figure this out.
As for culling: did you iterate over a list and compare game object coordinates every frame or did you solve it some other way?
Make sure you measure performance on your target platform. You may need to cull for older phones to run well, or not.
I think you might be right!
That’s really cool. These game objects are literally just images, no code or anything like that.
Exactly what you said; I iterate the bounds of each game object every frame and compare them with the camera bounds.
I noticed a one frame lag in the positions, so I had to account for that when making the calculation (by increasing bound size for the game object).
Just a suggestion; I was build this for one of my early prototypes. It uses BVS (dynamic bounding volume hierarchy) so you can cull the objects with it.
I wasn’t touch the lib since then but I guess it should be little more performant than iterating every object especially if you are moving the camera not the objects.
You can give it a try if you want. But I didn’t test it with new WebAssembly yet. Also current version is not using cpu very efficiently.
Meanwhile, a small (silly) question, what is culling?
simplest answer is turning on and off(disable-enable) the objects if they are in the camera bounds or not. But this is not the most efficient way as you can see above.
There are most efficient ways of doing it like using frustum culling or occlusion culling.
Ah, yes. And you do a go.get_world_position() for all of them and do some comparisons? Perhaps there’s optimizations that can be made, but it’s still bound to be pretty inefficient.
Another alternative for culling might be to use a collision object of type trigger that is attached to the camera and covers the screen. Enabled game objects on enter and disable on exit. Might be faster since you don’t have to check every frame and instead let the physics triggers and message system do the work for you. I’ve never tested this myself but have many times thought to do a benchmark test for culling and figure out what solution is the most efficient.
Nice ideas! My background is repeated, so it may be better to fake the whole thing and let each background type loop instead. I would have to figure out how to move to the next background type when needed.
Can i give you some advice? ParticleFXs are very useful for this kind of thing
Do you mean using particles as backgrounds? Tell me more!
You can make various particle FX emitters that emit sprites regularly and push them from right to left to create a scrolling background for your game. Just change the default particle for the sprite image that you want.
does that make sense? there are many disadvantages to this approach and it is not always suitable. it depends on your need. But if you’re using a factory that just sends out sprites, a particle FX emitter might be better.
Makes sense, thanks for the idea! Might not work for me, because I need to control the background speed precisely. But will store it in my arsenal.