clone vs. new t2dStaticSprite

#1 Same question here? Does anyone knows?

Thanks.

#2 Cloning is faster than creating new ones.

Object pooling is even faster. Create a set of objects and reuse them. This way you don't have to clone or create new ones on the fly.

#3 Thank you for your answer. First of all, excuse my english.

But I got more questions to ask now :).

What exactly do you mean by object pooling?
Right now I am storing my objects in SimSets or some of them in 2 dimensional array, 20x20 objects. I was using a lot of mounting and realized (thanks to debug banner), that I got about 2500 objects on a screen at average, which was caused by creating "parent" object and mounting another 10 to it. I am not using collision detection or any physics, but that amount caused a lot of performance issues.

So, from what you are saying I would create SimSet for every type (by type I mean e.g. diff. imageMap or effect (.eff), diff. dynamic fields don't make diff. type of object) of object and during game when I would need more of them I would clone them dynamically and add these clones to the right SimSet, and remove when I don't need them anymore.
This could be interesting with particles. As every time I need to create new object, I don't need to LOAD eff file form HDD, I just clone one of existing. This could slightly improve performance too.

On the other hand, I need to load about 100 TYPES of objects and some of them wont be needed during whole mission or even game and as far as I know, cloning is still bugged a bit as it reports some warnings to the console. Maybe instead of .clone() I could use .copy()? Is there any difference?


So all at all, I would like to find some recommendations for performance improvement. As far as I know, these things are noteworthy:
- use safeDelete instead of delete
- don't forget to unload particles, audio files etc. from globals to avoid memory leaks
- put as many sprites as you can together to ONE or few files (there is some limit determined by graphical card too), that got size power of 2, e.g. 4x4, 8x8, 16x16, 32x32... (could be 8x16 too?)
- (pre)load all possibly needed files from HDD in game OR/AND level loading screen
- be careful when using collision callbacks on many objects at once


Another question is, is it better to make the CORE of game logics in some kind of loop (made by schedule, or by ticks (onUpdateSceneTick), or onTimer) called every X(32) ms or is it better to have it event driven. Because loop really helps to control ongoing moving objects positioning, but PROBABLY drastically decreases performance.

So, yes, I know, it's about compromises. But nowadays, I would guess that simple 2D game with abound 2000 objects can't be performance issue. But it is :). So am I missing something?

Help would be highly appreciated. :)

#4 Please, ad. to my previous post in this thread - I wasn't able to find best practices for TGB (e.g. performance BP). Can anyone provide any resource?

#5 An object pool is how I ended up solving my problem, and it seemed to help out quite a bit. The way an object pool works is to create a set of objects to use, when you need one, you pull it out of the pool, when you are done with it you put it back into the pool. That way you aren't creating and deleting objects all the time.

Let me give you an example: Suppose you have some monsters, you have five on the screen. So you create five monster objects. When one dies, you put it into a 'dead monster' SimSet instead of deleting it. When you need a new one, you pull it out of the 'dead monster' SimSet instead of creating a new one. This can really help out if you are creating and destroying a lot of monsters, if you only ever have five monsters on the screen at one time, then even if the player kills hundreds of them, you will only ever create five monster objects, just reuse the same object over and over.

As for the slowdown, if you are manually setting the positions of your objects every frame, that could really slow things down. You should use the moveTo instead. You figure out where you want the object to go, how fast you want it to get there, and tell it to go. Torque will then worry about updating the position, and it should be faster. When it gets there, you can have it call a callback, and you figure out where it should go next, and send it on its way.

I hope that gives you some direction on what to try. Good luck.

#6 Wow, thank you. Perfect explanation of object pooling. Tried, worked perfectly. Maybe one should add destroying of objects, if they are "buffered" and not used for some time...

I am using moveTo, but have to have X, Y coordinates in array to control their positions on map (these coordinates are often changed by many events), I am checking current world position of every object and if it doesn't fit to X, Y position in array, I am calling moveTo, to get it to is intended position... but during that moving surrounding objects and conditions can change, so I am checking current world position of that moving object even during movement and force it to target again and again until its get to intended array X, Y. And that's maybe performance issue. Well, probably badly explained... need to improve my poor english skills really fast to be able to call for some help here :).

Never mind, main topic is resolved. I have many more questions, but at first I should try to find out answers alone :).

Thanks again.