Performance with large number of objects?

Post reply
0 favourites
  • 11 posts
From the Asset Store
Firebase Utilities PRO- Analytics, Dynamic Links, Remote Config, Performance, Crashlytics
$12 USD
Firebase: Analytics, Dynamic Links, Remote Config, Performance, Crashlytics on Android, iOS & Web Browser
Sparsha's avatar
Sparsha

  • Hi,

    So I'm making this evolution simulator for experiment purposes (not a game) and stumbled upon performance issues.

    There is no physics but quite a large number of objects (simple circles) with 1-3 additional objects attached and some instance variables and calculations.

    At 300-400 objects the simulation stutters and at ~500 it practically stops.

    So I was thinking, I know that this is high-level code etc., but still, shouldn't modern computers be able to easily handle a few hundred moving circles?

    Ideally I would like to be able to simulate a few K of objects. Is there a way around this? I don't need to run it on mobile at all.

  • Hi pirx

    Check out https://www.construct.net/en/make-games/manuals/construct-3/tips-and-guides/performance-tips

    I recommend running your code in debug mode and seeing what is using up your CPU time. It can be easy to use up your CPU budget, particularly with a large number of objects on screen. I expect your event sheet is probably using the most time.

    Without seeing your project it's hard to diagnose it. There's a large number of skilled users in the community who are probably better at optimising projects than I am, but they will still need to see at least part of your project to help you.

  • Thanks!

    Just to be clear:

    If I have a one-screen white layout (1920x1080), and say 1000 small circles moving via Bullet and bouncing of walls and each other, and given that everything is as optimized as it gets, do you think it should be more or less handle-able on a fast computer?

  • There is a really dirty hack what you can try. If the circles are not to fast it should work.

    You can try to enable the bullet only every 2*dt or 3*dt sec.

    + System: Every 3×dt seconds

    -> Circle: Set Bullet Enabled

    + System: Else

    -> Circle: Set Bullet Disabled

    This can have bad side effects if you need the precision of collision checking every dt sec.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I'm building a gameplay proof of concept in C3 and ran into a similar issue. In my experiment, there were new circles that were generating additional circles, which would then move to a specific location, and would be destroyed. There would be a few hundred circles (with attached arrays for state) on the screen at a time, and performance would get very bad WAY sooner than I anticipated.

    I used the debugger and discovered that I had made a small mistake in my function to create my circles, and that the number of circles being created were being increased by one each time a new circle generator would be created. This resulted in many thousands of circles being created after a short period of time; they were just stacked and therefore "invisible".

    I anticipate you are experiencing something similar to this, and that you'll find your issue in the debugger, because now I literally haven't been able to get a frame rate hit, regardless of how long I let the circle generators continue to be created.

  • Define:

    > with 1-3 additional objects attached and some instance variables and calculations.

  • Define:

    > with 1-3 additional objects attached and some instance variables and calculations.

    Each circle (a container) has a larger circle (as a proximity sensor), a 1x1 px anchor sprite for making sure pinned labels don’t rotate, two labels and an invisible shooter sprite that’s used for some interactions and a dictionary object (for storing genes).

    There’s about 10 instance variables and more or less 20 different simple calculations “every second” on these (e.g food -1). On collisions there’s an additional calculation for pointing the shooter sprite at the colliding object.

    EDIT: ah that’s more than three but initially there was only one label, the larger circle and the anchor sprite. The decline in performance at large number of instances was just as noticeable as currently though.

  • teahousemoon

    Good point about the debugger but unfortunately in this case the number of circles is strictly controlled and displayed on screen in a statistics box and new ones are created only sporadically on reproduction in a visible manner. So it is practically impossible that more than I know of would be created by mistake.

  • Asmodean

    Nice trick for future reference but I need collisions to be checked kind of precisely within time so I would not take risks here. ;)

  • Nepeo

    Good points.

    I’ll have a look at what’s eating my resources the most. Also will post capx if there is no apparent cause.

  • pirx

    are the labels text objects that get updated every tick? that can be a big performance hit right there...

    also, watch out for doing unnecessary for each loops, and there are things you can do to keep collision checks down too...

Post reply
  • 11 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)