Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
FPS OnEnterFrame and bottleneck performance — Gideros Forum

FPS OnEnterFrame and bottleneck performance

piepie Member
edited February 2014 in General questions
Hi, I'm trying to put together a game with "a lot" of enemies, each one checking onEnterFrame how to behave on its own conditions.

I was wondering if it could be possible to edit the onEnterFrame event dispatcher, so that I could make alternate checks (on even/odd #instances for example) and have them perform their things(check conditions) only every 30/2 fps.

Maybe I could achieve this dispatching "onenterframeEven" and "onenterframeOdd" events, in a standard "onenterframe" call? (Just tought it now, while writing down my question.. I will try asap: any suggestion is welcome though :) )

I think that my "bottle neck" happens because all my instances together are asking for some attention, in the very same instant, and most of times this check is useless.
The game is turn-based, they only act when it's the "ENEMY" turn, but they do it asap as the turn value changes: so everything freezes on change-turn until everyone got what it wanted.. (some secs).

I have the feeling that the prototype performance (if i add too many enemies - let's say about 20 - each one featuring 10 instances of the class making the "onEnterFrame-Check") increases if I choose 15FPS on the desktop player. Could this be?
Unfortunately I can't check if this is true on a real device because I can't export to 15 fps - unless there is an unknown trick to do it. :)

Thank you

Cheers!
P.

Comments

  • ar2rsawseenar2rsawseen Maintainer
    edited February 2014 Accepted Answer
    @pie I'd say your problem is that you do everything in one single enterFrame event.

    So for example if I do something like:
    local sprite
    for i = 1, #sprites do
        sprite = sprites[i]
        sprite:setX(sprite:getX() + 100)
    end
    I will move all sprites in the same enter frame, so visually so will all move the same. Even if you do not execute the code inside on enter frame event, still, this code is atomic single block and will be executed in same single frame event.

    But if I want to move each sprite and delay moving the next sprite, so visually they would appear to be moving sequentially, then you could do it like this (again you execute this even outside enter frame event):
    local sprite
    local timer = Timer.new(100, #sprites)
    local i = 1
    timer:addEventListener(Event.TIMER, function()
        sprite = sprites[i]
        sprite:setX(sprite:getX() + 100)
        i = i + 1
    end)
    timer:start()
    the object will be moved in different frame events, thus first one will jump, then after 100 milliseconds other will, etc.

    I think the same can be used to divide the single task between multiple enter frame events

    Hope that helps :)
  • Of course it helps: at least it's worth a try, I'll let you know how it goes. :)
    Thank you very much!

    Wasn't there a reason to avoid the use of "timers"?
    I'm quite sure I read this somewhere on this forum.

    Thank you again

    P.
  • Most probably Timers where optimized since then ;)
  • You might also make sure that the images for your enemies are being pulled from the same texture atlas (as much as possible, anyway). Texture-swapping is a killer.

    Likes: ar2rsawseen

    +1 -1 (+1 / -0 )Share on Facebook
  • OZAppsOZApps Guru
    Accepted Answer
    Some tips:
    1. in the for i = 1, #sprites
    avoid updating the position for the sprites that off screen

    2. if you want smooth performance then make it time based rather than fps based. i.e. use the deltaTime between the last time and this time enter_frame was triggered and use that to multiply that with the speed. e.g. if the sprite was moving 100 px, now it will move dTime * 100

    @arsawseen,
    even if the Timers are optimised, they are hardly something to use in a game loop. Because before the timer is triggered, what is the sprite is shot and removed...

    The sprite index *could* change and so would so many other things.
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • piepie Member
    edited July 2014
    Of course it helps: at least it's worth a try, I'll let you know how it goes. :)
    I'm sorry I didn't follow up on this: use of timers suggested by @ar2sawseen to "delay" each call, improved performance, A LOT.

    :)>-

    Thank you all for your answers and suggestions :)
Sign In or Register to comment.