Transition.to bug

MikeHart · April 21, 2010, 10:41am

Hi folks,
when you constantly use transitions, the framerate goes down after a while. This bug exists in all current and beta version. This is kinda a show stopper for me as my whole concept relies on transitions.
Here is a little script that shows the effect in the simulator. I noticed the same on my IPod in my game:
display.setStatusBar( display.HiddenStatusBar )
local tPrevious = system.getTimer()
local millisec, framecount = 0,0
local spr = nil
local onComp, OnComp2
grp = display.newGroup()

onComp = function (target)
transition.to(target, {time=math.random(1500,2000), x = math.random(20,300),y = math.random(20,460), onComplete=OnComp2})
end

OnComp2 = function (target)
transition.to(target, {time=math.random(500,1000), x = math.random(20,300),y = math.random(20,460), onComplete=onComp})
end

for i = 1,30 do
spr = display.newCircle( 0, 0, 16 )
spr:setFillColor(255,0,0,255)
spr.x = math.random(20,300)
spr.y = math.random(20,460)
grp:insert(spr)
transition.to(spr, {time=math.random(500,1000), x = math.random(20,300),y = math.random(20,460), onComplete=onComp})
end
local fpsText = display.newText( “030”, 0, 0, “Verdana-Bold”, 12 )
fpsText:setTextColor( 255,0,255 )

function onFrame(event)
local tDelta = event.time - tPrevious
tPrevious = event.time
framecount = framecount + 1
millisec = millisec + tDelta
if millisec >= 1000 then
fpsText.text = framecount
millisec, framecount = 0,0
end
end

Runtime:addEventListener( “enterFrame”, onFrame )
[import]uid: 5712 topic_id: 832 reply_id: 300832[/import]

seanh · April 22, 2010, 3:36pm

I’ve added this to our bug tracker. [import]uid: 3 topic_id: 832 reply_id: 1859[/import]

Abica · May 5, 2010, 12:40pm

I’ve taken this same code, changed the time step in the transitions to 1000 and changed them to an alpha transition instead of an x, y. I also cranked it up to 100 sprites. I was still able to replicate the memory leak Mike is talking about, albeit far slower than with the x, y transition. [import]uid: 70 topic_id: 832 reply_id: 2159[/import]

carlos_m_icaza · May 5, 2010, 1:38pm

Bumped up the priority

C [import]uid: 24 topic_id: 832 reply_id: 2161[/import]

fpassa · May 10, 2010, 1:04pm

Hi guys,

I have many transition.to in use in my Game Ultimate Coins Game, but one of the things that I discovered was to remove invisible and/or unnecessary objects, that´s means put all of them to isVisible=false and then to nil.

I was 3 long days trying to understand why after few playback of my game, in the Challenge 3, where a rolled coin appears on the screen it started to move slowsly every time this level plays. I was reviewing my entire code. I tried to change transition.to calls, but problems persisted. At the end, I found that I was keeping some hidden graphics object in memory, like button not used. The solution was to put them to nil. Then everything goes fine.

I have a jailbreaked iphone, so I have a modified version of Status Bar at my iphone which allows me to put available memory counter on it, near to battery status. So, I kept the status bar unhidden during my gameplay to detect memory lacks. My game was eating 2 MB every time I pass to new level. At 8 Mb available, problems start in object moving.

That´s is why I asked to have a complete debugging tool or memory tracker in CORONA SDK, to avoid these kind of problems, because you will not see them in simulator, never! You have to put your app on your device and keep running long time to see what happens.

At least that is my experience with this issue. I hope it can be useful to someone here.

Regards,

Flavio. [import]uid: 3022 topic_id: 832 reply_id: 2260[/import]

carlos_m_icaza · May 10, 2010, 1:50pm

Case # 175

carlos [import]uid: 24 topic_id: 832 reply_id: 2265[/import]

Eric · May 10, 2010, 5:19pm

Sorry for the delay in replying.

This is a bug in the transition library. The fix will be in the next beta drop.

If you can wait a few days, that’d be ideal, but if you can’t, here is a workaround. This isn’t 100% ideal because it introduces a bit of overhead. But basically, using performWithDelay as a way to decouple the transition endings will work.

display.setStatusBar( display.HiddenStatusBar )
local tPrevious = system.getTimer()
local millisec, framecount = 0,0
local spr = nil
local onComp, OnComp2
grp = display.newGroup()

for i = 1,30 do
 spr = display.newCircle( 0, 0, 16 )
 spr:setFillColor(255,0,0,255)
 spr.x = math.random(20,300)
 spr.y = math.random(20,460)
 grp:insert(spr)

 spr.state = 0

 function spr:timer( event )

 if self.state == 0 then
 self.state = 1
 transition.to(self, {time=math.random(1500,2000), x = math.random(20,300), y = math.random(20,460), onComplete=self})
 else
 self.state = 0
 transition.to(self, {time=math.random(500,1000), x = math.random(20,300), y = math.random(20,460), onComplete=self})
 end

 end

 function spr:onComplete( event )
 timer.performWithDelay( 1, self )
 end

 transition.to( spr, {time=math.random(500,1000), x = math.random(20,300), y = math.random(20,460), onComplete=spr })

end

local fpsText = display.newText( "030", 0, 0, "Verdana-Bold", 12 )
fpsText:setTextColor( 255,0,255 )

function onFrame(event)
 local tDelta = event.time - tPrevious
 tPrevious = event.time
 framecount = framecount + 1
 millisec = millisec + tDelta
 if millisec \>= 1000 then
 fpsText.text = framecount
 millisec, framecount = 0,0
 end

end

Runtime:addEventListener( "enterFrame", onFrame )

[import]uid: 54 topic_id: 832 reply_id: 2278[/import]

fpassa · May 10, 2010, 8:27pm

Eric,

The reality of your code is that even if you change the last call of Runtime:addEventListener(“enterFrame”, onFrame) with timer.performWithDelay(x, onFrame,0), where x would be a number between 30 to 100, you’ll realize that FPS is affected on text label, changing from 31 to 16 if you use x=100, but circles objects continue moving at the same speed; it means, that FPS measure is not true in regarding of objects on the screen; at least in simulator.

I didn’t yet test it on my device.

Regards,

Flavio. [import]uid: 3022 topic_id: 832 reply_id: 2286[/import]

Eric · May 10, 2010, 9:37pm

fpassa, I don’t completely understand your comment… [import]uid: 54 topic_id: 832 reply_id: 2287[/import]

MikeHart · May 10, 2010, 9:48pm

Flavio,

the FPS messurement is correct.
The movement is time based, so the circles just make bigger jumps within each frame.

And your theory about the hidden objects doesn’t grab here as I don’t create new objects during runtime, just once at the beginning.

@Eric,

thanks for the conformation of the bug. Till it is fixed I will stop the development of my game as this is crutial for my approach.

Michael

[import]uid: 5712 topic_id: 832 reply_id: 2288[/import]

fpassa · May 11, 2010, 6:46am

Hi guys,

I remarked only the fact that measuring FPS outside of drawing rutine only reflect that. If you change the cycle of this part of the code:

function onFrame(event)
local tDelta = event.time - tPrevious
tPrevious = event.time
framecount = framecount + 1
millisec = millisec + tDelta
if millisec >= 1000 then
fpsText.text = framecount
millisec, framecount = 0,0
end

end

you are not altering FPS response itself from the perspective of view of circles objects. If you change the enterFrame runtime listener and replace it by timer.performWithDelay(100, onFrame,0), you will notice a FPS mark of 16 FPS, but circles still moving at the previous velocity.

I guess if the idea is to mesure the current screen refresh including drawing, that part of the code should be between the For cycle, where it will reflect the right FPS of transition.to. But what is realy noticed here, is that transition.to works (at least it seems…) on different threads, which gives better performance and may be we can address 30 FPS sustained.

But, what happens if we replace transition.to animation to manual transition, like object.x=… object.y=… and a formule to recalculate its animation based on time between each cycle, like you do with

local tDelta = event.time - tPrevious
tPrevious = event.time

schema. If we do that and put the measure between that new manualy cycle, does CORONA give 30FPS sustained?

Regards,

Flavio. [import]uid: 3022 topic_id: 832 reply_id: 2296[/import]

Eric · May 11, 2010, 8:46am

All activity happens on the same thread. “enterFrame” events are synchronous with all drawing, including transition.to. So as long as those are not artificially slowed down, an FPS calculation based on enterFrame would have the true FPS. Using performWithDelay does introduce an artificial slowdown, which would change the effective rate of drawing, but not the actual animation frame rate. Generally, FPS will remain 30 unless there is some CPU intensive calculation being done. [import]uid: 54 topic_id: 832 reply_id: 2300[/import]

MikeHart · May 14, 2010, 10:45pm

Thanks ANSCA, seems to be fixed. Damn and I was hoping for a slow weekend. Now I don’t have any excuses to not work on my game. [import]uid: 5712 topic_id: 832 reply_id: 2445[/import]