FPS OnEnterFrame and bottleneck performance

pie · February 2014

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.

ar2rsawseen · February 2014

@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

pie · February 2014

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.

ar2rsawseen · February 2014

Most probably Timers where optimized since then

FlimFlamboyant · February 2014

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.

OZApps · February 2014

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.

eezing · February 2014

@pie

I just posted something that could help you out a bit.

http://giderosmobile.com/forum/discussion/4506/move-sprites-more-efficiently#Item_1

pie · 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

Howdy, Stranger!

Categories

In this Discussion

Top Posters

FPS OnEnterFrame and bottleneck performance

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

FPS OnEnterFrame and bottleneck performance

Comments