Highlighted

Large number of objects - strange movement

Engaged ,
Mar 20, 2014

Copy link to clipboard

Copied

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

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.

TOPICS
Development

Views

387

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Large number of objects - strange movement

Engaged ,
Mar 20, 2014

Copy link to clipboard

Copied

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

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.

TOPICS
Development

Views

388

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Mar 20, 2014 0
Engaged ,
Mar 21, 2014

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2014 0
Adobe Community Professional ,
Mar 21, 2014

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 21, 2014 0
Engaged ,
Mar 22, 2014

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 22, 2014 0
Adobe Community Professional ,
Mar 22, 2014

Copy link to clipboard

Copied

Sounds good. Some people use timers, without realizing that it could potentially lengthen the duration of the frame. enterframe will do its actions during that time the frame is being shown.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 22, 2014 0
Engaged ,
Mar 22, 2014

Copy link to clipboard

Copied

I haven't come accross this myself, but I've heard Timers can also be re-entrant in certain (specific) situations - i.e. can be fired again before they have finished execution.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 22, 2014 0