Events optimization

0 favourites
  • 5 posts
From the Asset Store
Very simple code without excess options (15 events for server and 11 events for client)
  • Do I need to bother myself with disabling events referring to objects that do not exist on the current layout?

    I have a bunch of collision checks, overlapping, overlapping at offset and for each that set values/object manipulation/code animation that runs per tick / every X sec.

    I don't see much difference when disabling these events, but I have a strong computer and I wonder if on weaker machine it might cause more lagging.

  • I recommend doing it anyways. I'm developing for mobile and disabling groups of events has significantly improved performance for me.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Develop your code with as much optimization as you can do. Especially if your target platform is mobile.

  • Thanks guys, the project I refereed to is aimed for desktops/laptops running PC, MAC, LINUX using nwJS and possibly xbox/ps4 html versions.

    I remember reading in the manual that events usually does not require much processing and should not affect performance too much, on my debugger I get an average of 4% cpu usage for all the events on 90% of my layouts and on busy layout it can peak up to 7-8%, using an i5 3.40GHz processor.

    I have a total of 1300 events and about 700 of them are the core shared game events.

    But I guess some extra optimization couldn't hurt anyways.

    What is the best practice for this?

    I thought of 2 options:

    1. On start of layout check object count per event, if count = 0 then disable event.

    2. attaching another event sheet for the specific layouts with the extra events. no extra events needed, but running and maintaining another bunch of event sheet per objects.

  • The golden rule of performance is to make measurements. If you can't measure a difference, it doesn't matter either way, and you're probably wasting your time until you find something that makes a measurable difference.

    Note that testing a powerful desktop machine might make it difficult to measure any changes, since it will always be fast enough - ideally you want the weakest device that you intend to be targeting to test on. (For example for a Steam desktop game the lowest-end device is probably still a decent-ish gaming laptop, whereas for a mobile game the lowest-end device would be a cheap Android phone.)

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)