Skip to main content
Projectitis
Inspiring
March 21, 2014
Answered

Large number of objects - strange movement

  • March 21, 2014
  • 1 reply
  • 719 views

Hi all,

My current game has a large number of moving objects (but not overly large) - about 100 moving about on screen at once.  Most of these are bullets and very small (e.g. 16x16). I am using GPU mode.  All graphics are bitmaps, and furthermore, I'm using object pooling for everything, and my bullets and enemies etc are kept in linked lists (which are faster than Vectors<>).  All bullets share the same bitmapData.  There are perhaps 15 different bitmapData in use.

In some situations - usually after unleashing a bullet storm of some sort (say 30 bullets at once flying out in all directions from the player) - the graphics behave strangely.  The framerate is still high, but some of the bullets will move in a staggered sort of way instead of smoothly.  They'll move forward for a bit, then slow or stop, then shoot off again for a bit.  This tends to happen towards the edges/corners of the screen while the action in the middle is ok. 

Has anyone noticed anything like this before?

The only other thing of any large consequence is a bitmapData that covers the entire screen in the background.  It's bitmapData is actually 0.25% the width and height of the screen and then stretched 400% to fit.  Whenever an enemy is destroyed a 'splat' is rendered to the bg, which then needs to be updated.

Cheers,

Peter

This topic has been closed for replies.
Correct answer Projectitis

Sorry everyone. This was my own dumb error.

I tracked it down to my code that removed bullets from the linked list when they exited the screen. This would cause the rest of the list not to be processed until the next frame.  With a large number of bullets leaving the screen at once, this was producing some pretty nifty effects.

1 reply

Projectitis
ProjectitisAuthorCorrect answer
Inspiring
March 21, 2014

Sorry everyone. This was my own dumb error.

I tracked it down to my code that removed bullets from the linked list when they exited the screen. This would cause the rest of the list not to be processed until the next frame.  With a large number of bullets leaving the screen at once, this was producing some pretty nifty effects.

Colin Holgate
Inspiring
March 21, 2014

Glad you figured it out. Out of interest, are you using timers or enterframe to do the updating?

Projectitis
Inspiring
March 22, 2014

Thanks.  Bascially enterframe. I have one ENTER_FRAME listener at stage level that grabs the event at capture phase and kills it, then I use callbacks exclusively (no events).

Over the past years i've built a whole framework around this thats super fast.  Objects that receive enter_frame events register callbacks in a linked list that is fired from that one 'real' enter frame.  I have tweening systems (that mirrot greensocks ones) etc all included.