Moving 300+ objects for Bullet Hell Game [Performance Issue]

#1 Rendering 300+ sprites shouldn't be a problem. But since these are bullets, I'm guessing there's more going on than just rendering sprites. Does each bullet have its own component(s) to apply physics and collision checking? With each bullet handling tick processing, this is probably bogging down the engine.

By breaking down this problem, we might be able to think about a different solution for your game that results in the same effect. Can you email me a screenshot that shows the action? Is it important to have all 300 bullets in play at once? Instead, can there be 'groups' of bullets that render on screen as a cluster of bullets, but are logically one TorqueObject? Can the stream of bullets be rendered as particles with the impacts and collision processed by fewer 'invisible' bullets?

Other ideas might include changing the tick processing of the components so that they update their state every other, or every third tick.

John K.
www.envygames.com

#2 Each bullet have a collision component (to hit the hero) and a physics component (for velocity). For this test no other component is being used, but in the final game we are going to add a third component that will wait for a specific tick to apply an impulse.

Unfortunately as it is a "bullet hell" type of game, the behavior of each bullet is important to create different patterns. Therefore, creating a cluster of bullets is probably not going to allow for very interesting and/or flexible patterns.

We managed to greatly improve the performance by creating our own pool, but it is still not good enough. We are trying now to remove the collision component and checking manually nearby the hero.

Any other suggestions?

#3 What type of collision shape are you using? Circle-to-circle collisions are generally much faster than poly-to-poly.

#4 Hope you don't mind me putting in a quick question here but, how do you make circle collisions other than making a circleish poly?

#5 Torque X only supports polys from what I can tell(other torque engines have more than one type of collision shape)

However, it wouldn't be too much of a problem to code your own Circular collision component and some sort of manager to test the collisions for you.

A good general tutorial on how circle collision detection works and how to put together a good framework for it can be found here:
www.shmup-dev.com/forum/index.php?topic=1636.0

Anywho, your custom component would have to communicate with your custom collision handler on the OnRegister and OnUnregister to tell it that it's scene object is a collider(and that it's been removed). Since its just your player and enemy bullets that really need it, just make it work for those two, and do the rest with the built in for ease of use. So your handler would just have to test between the player and the bullets, thus making it pretty simple to code. The component would have an OnCollision Delegate that is set to be what is called when a collision happens.

The real bad thing is you cant use the editor to visual do the circles, but you can get a rough estimate and use numeric values to set that and you should be fine.

I haven't needed a system like this in the shmups Ive been coding, but I'm not a huge fan of pure bullet curtain games. I like em manic, but not that manic.

#6 I was doing something similar in TGB, while it isn't C# or XNA, I found the best performance with collision was to do absolutely no collision checks from enemy bullets, instead have them set to receive collision only from the Player, and have the Player be the object which sends collision. With the pooling, I'm not sure how the pool feature works yet, but what I ended up doing was creating a list (simset) of inactive enemy bullets, about 2000, and just using those, recycling bullets into the list (and disabling them) instead of destroying them.