Pick by evaluate using more CPU than For each?

0 favourites
  • 6 posts
From the Asset Store
Pick Up Items Sound effects for your game, Take them for a ride right now and you will worry no more.
  • I was messing around trying to optimise some parts of my game tried out picking objects (pick by evaluate) instead of using for each, and seemed it used more CPU than a for each loop on ALL objects in the family.

    Even when the picking event returned false and not running any actions it was using more CPU than the For each event doing the same thing every tick.

    How is that possible?

    In my mind the picking would limit the amount of actions to be done as an optimisation but turns out it's using more CPU. If the picking event didn't find a match the event would be false right? nothing to be done... so how come it uses more CPU than running a for each loop with no picking...

    Very strange.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 2 things I guess:

    -the evaluation of the expression might be simply taking more time than the actions (don't think conditions are instantaneous, in some cases they take more time that actions).

    -the CPU measure of C2 is not accurate enough for a small case (and even for larger ones), it is really a ballpark figure and nothing more, if the difference for the small case is minor, then don't really care about it that much, as the inaccuracy and debug alteration might play a bigger role.

  • Depends on the amounts of objects, and what the for each is supposed to do.

    And like Aphrodite mentions, it depends on the evaluation too.

    Its like comparing oranges and apples.

    Also,

    Have you tried pick by unique ID ?

    Or pick by comparison ? (without pick all)

  • 2 things I guess:

    -the evaluation of the expression might be simply taking more time than the actions (don't think conditions are instantaneous, in some cases they take more time that actions).

    -the CPU measure of C2 is not accurate enough for a small case (and even for larger ones), it is really a ballpark figure and nothing more, if the difference for the small case is minor, then don't really care about it that much, as the inaccuracy and debug alteration might play a bigger role.

    Thanks. Difference is not that huge. But there are some tradeoffs.

    The Picking way, Uses less CPU that the For each way, but as the sprite count increases, and seems fairly constant even with large numbers of sprites in the layout.

    The for each way gets more heavy as the number of sprites increases, but is using less CPU when the sprite count is low.

    i think i have to do some more experimentation on the picking events.

    Right now I'm using picking sprites in several steps with conditions.

    Condition1, picks only the sprites on screen.

    Condition2, picks only the sprites on the specific layer.

    Condition3. picks by evaluating only the sprites(in a family) that are above the player.Y & left of player X & distance is less than 150px from player.

    Most of the time this limits the picking to 1 or 2 sprites picked.

    If all the conditions are met a function is called & Moves the picked sprites to another layer, so they will not be picked again.

  • Did you try a family variable?

    Also it's a process of elimination, so if you have a condition that makes the stack smaller starting out, use it first.

  • Condition1, picks only the sprites on screen.

    Condition2, picks only the sprites on the specific layer.

    Condition3. picks by evaluating only the sprites(in a family) that are above the player.Y & left of player X & distance is less than 150px from player.

    Condition1. picks by evaluating only the sprites(in a family) that are above the player.Y & left of player X

    Condition2, picks only the sprites on the specific layer.

    Condition3. distance is less than 150px from player.

    Try that

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