Is createSprite() and removeSprite() costly?
-
Hi!
Does anyone know if creating and destroying sprite object is a costly (in terms of performance) operation in Fuze?
I have designed all objects in my shmup that way, so every time a bullet is fired, a new sprite is created and added to an array. When the bullet moves outside the screen, the sprite is destroyed.
So far, everything goes pretty smoothly, but I was thinking of redesigning it to use a pool of sprites instead... Then all sprites would be created at game start, and each each would have some sort of flag for when they are in use or not. Maybe I can then have a pointer saved that has the "lowest indexed sprite not in use", so that I do not have to loop through the entire array each time...
So far, I haven't experienced any performance issues, but I'm thinking that I might eventually.
-
Nice thought... It may just be a good idea to recycle them rather than destroy what you know you're going to need. Set the limit to what you need. Have a flag on the bullet to say whether it's active or not, set it to inactive when it leaves. Set a condition to only draw active ones.
-
I haven't checked how quickly Fuze creates and removes sprites, and I haven't checked your code. But what I'm hearing is, that you don't experience any performance issues yet.
Although I wouldn't ignore the thought that you might eventually need optimization, I think it's better to focus on the design of your code in stead.. For example, if you manage to separate out your sprites logic into independent user-functions, keeping the bulk of your implementation the same, since that performs fine at the moment.
This way you can continue to work on what you want your game to be for as long as possible. Then once you notice that you really need better performance from your sprite logic, then you can revisit those functions and go from there.
This way you can avoid something called
premature optimizationand in the end, the skill to write code that is easy to maintain, is more useful than to write code that performs well. Because if code is easy to maintain, it should be more easy to improve the performance as it is necessary. But if code is highly optimized, even though it wasn't even necessary, it might be complex and hard to introduce new features without overseeing the impact. -
It wouldn't hurt to create all the sprites up front as long as you don't end up exacerbating things by needing too much logic around finding the next free sprite because you could quickly find you're losing performance there. As you say, maintaining a simple int that says which is the lowest free sprite index is probably simplest and when you free a sprite, update that index if the sprites index if lower than it, likewise when you create a sprite set that index to that one +1.
Given that sprites can hold custom properties it's simple enough to have an int that defines the kind of sprite that it is (in terms of your game) and call different functions for different behaviour logic.
