What's the Best Method for Processing Projectiles?
by practicing01 · in Torque 2D Beginner · 04/04/2013 (12:30 am) · 8 replies
I'm thinking of either attaching an onUpdate() to each projectile or having just one function running onUpdate() that goes through all projectiles. I can't use physics because the projectiles can move in non-linear paths. Is there a difference, performance-wise, between each projectile having an onUpdate() and just one onUpdate() function going through all projectiles? Is there a better method for processing projectiles using torquescript (I don't want to touch the source because I don't understand it).
#2
Edit: I might have a solution using moveTo()...
04/04/2013 (2:15 am)
By non-linear path I meant instead of a straight line from start to finish, have the projectile's path be in the shape of a wave or zig-zag, etc. Sorry for using wrong terminology. I realize that having so may onUpdate() callbacks could cause lag, that's why I wanted to ask for advice in the forums. I don't want to mod the source because I don't know how and don't want to spend months learning. Anyone have any radical ideas?Edit: I might have a solution using moveTo()...
#3
You don't have to use physics for just collision...
Edit: Sorry, now that I realize it's for position updating.. either a schedule or an OnTimer function would be your best methods currently.
04/04/2013 (6:24 am)
Why don't you just use onCollision callbacks?You don't have to use physics for just collision...
Edit: Sorry, now that I realize it's for position updating.. either a schedule or an OnTimer function would be your best methods currently.
#4
You can all have a pool of projectiles created and re-use them - only creating new ones if necessary. Then you can have a single onUpdate() being called for the factory object in which logic for your projectile pool is performed.
It's a balancing act but I find for things like particle and projectile (where there are lots of them), it's better to handle to collision callbacks (dealing damage, etc) on the object receiving the collision.
Just my opinion and heavily influenced by XNA factory design patterns.
04/04/2013 (6:34 am)
I like to create a scene object that manages projectiles. Call it a projectile factory object.You can all have a pool of projectiles created and re-use them - only creating new ones if necessary. Then you can have a single onUpdate() being called for the factory object in which logic for your projectile pool is performed.
It's a balancing act but I find for things like particle and projectile (where there are lots of them), it's better to handle to collision callbacks (dealing damage, etc) on the object receiving the collision.
Just my opinion and heavily influenced by XNA factory design patterns.
#5
Edit: Thanks to Tim-MGT, using trig calculations is what's causing the problem. Not sure how i'm going to fix this...
Edit: Thanks to Tim-MGT again :), there was a loop iterating quite a bit, toned it down and the results are tolerable. Side-note: I'm pretty sure clone() is bugged.
04/08/2013 (6:45 am)
For moving the projectiles, I made a simset containing the path vectors and call a moveTo() for the first vector. Then I use onMoveToComplete() to call moveTo() to the next point etc. There is a lag spike when I create the projectile sprite. I tried creating one and then using clone() but I still have to add() them to the scene, I guess that's where the lag spike happens. I'll think about making a pool. Anyone have any other suggestions to stop the lag spike please?Edit: Thanks to Tim-MGT, using trig calculations is what's causing the problem. Not sure how i'm going to fix this...
Edit: Thanks to Tim-MGT again :), there was a loop iterating quite a bit, toned it down and the results are tolerable. Side-note: I'm pretty sure clone() is bugged.
#6
Your pool idea served us well in the Tower Defense template for 3SS. Basically we set a minimum pool size and then added extra projectiles to the pool if needed. This stabilized at an acceptable frame rate and avoided large hits for firing large numbers of projectiles.
We also pooled enemies.
04/08/2013 (1:52 pm)
Clone() is slow....Your pool idea served us well in the Tower Defense template for 3SS. Basically we set a minimum pool size and then added extra projectiles to the pool if needed. This stabilized at an acceptable frame rate and avoided large hits for firing large numbers of projectiles.
We also pooled enemies.
#7
When you load a Scene from a .taml file, all of the Assets in the .taml file will obviously be loaded when the game starts.
IF you create objects (such as bullets) on the fly during the game however, the first time you will instance an object, the asset will have to be loaded for the first time, which might create a slight delay or slowdown as the imagefile is loaded, etc.
To circumvent that, you can specify what assets to preload in the level's taml file.
So even if you don't have a bullet initially present in your level, you can add its asset to Scene.AssetPreload so that when you create the projectile, its asset will already be loaded and the instancing will be many many times faster.
04/08/2013 (4:43 pm)
A final performance tip that can be really useful when creating large amounts of objects at runtime : When you load a Scene from a .taml file, all of the Assets in the .taml file will obviously be loaded when the game starts.
IF you create objects (such as bullets) on the fly during the game however, the first time you will instance an object, the asset will have to be loaded for the first time, which might create a slight delay or slowdown as the imagefile is loaded, etc.
To circumvent that, you can specify what assets to preload in the level's taml file.
<Scene>
<Scene.AssetPreloads>
<Asset Id="@asset=ToyAssets:Particles1" />
</Scene>So even if you don't have a bullet initially present in your level, you can add its asset to Scene.AssetPreload so that when you create the projectile, its asset will already be loaded and the instancing will be many many times faster.
#8
Using different joint types and joint motors you could get a variety of bullet path behaviors "for free" from the joint physics-- sinusoidal oscillation, spirals, speeding up and slowing down, and so on. Since it is already implemented in the physics system it is pretty easy to play with it and see what sparks your imagination.
04/08/2013 (5:55 pm)
You could create an invisible, kinematic object moving on a straight line and attach your visible, dynamic bullet object to it using a joint. A springy joint would let the object bounce around and give you your wavy motion. A prismatic joint and joint motor could give you the zig-zag. You would have to play around a bit with the initial velocities of the anchor and bullet but the system has a lot of flexibility.Using different joint types and joint motors you could get a variety of bullet path behaviors "for free" from the joint physics-- sinusoidal oscillation, spirals, speeding up and slowing down, and so on. Since it is already implemented in the physics system it is pretty easy to play with it and see what sparks your imagination.
Associate Simon Love
I am not sure what you mean by non-linear paths either. Do you mean parabolic curves and such?
Performance-wise, I can't say which one would be the fastest between setting each projectile's updatecallback to true or putting all projectiles in one simset and calling an update function on each object in the simset. Logically-speaking, both methods would achieve the same result.
Executing a callback on each projectile on every tick can be extremely costly in terms of performance if you plan to have several projectiles as in a bullet-hell type shooter.