basic question: dynamic calling of methods? reusable function?

[jwwtaker]

I come from a PHP background, where making code reusable is simple. My question is probably extremely simple but cant seem to find the answer in the docs. If I want to reuse a block of code how would i do this? background of the situation is:

i have 5 strings.

text1 = “line1”;
text2 = “line2”;
text3 = “line3”;

I want to fade this text in and out using calls similar to

timer.performWithDelay(3000, displayVal(text1, 50, 150) );
timer.performWithDelay(3000, displayVal(text2, 30, 150) );
timer.performWithDelay(3000, displayVal(text3, 40, 150) );

local function displayVal(text, x, y)
textBox.x=x;
textBox.y=y;
textBox.text=text;
transition.to(textBox, {time=1000, alpha=1})
transition.to(textBox, {delay=3000, alpha=0, time=1000})
end [import]uid: 6317 topic_id: 914 reply_id: 300914[/import]

[Abica]

I’m not completely sure I understand what you’re attempting to do. Do you want a single piece of text on screen that has a fade transition between 5 different phrases, or are you trying to reuse your transitions across 5 variables? [import]uid: 70 topic_id: 914 reply_id: 2130[/import]

[jwwtaker]

trying to have 1 line fade in, then out, then another fade in then out, then another fade in then out, and so forth. I’ve just run into the issue of reusing code in general in a couple of other places too, being able to dynamically call methods i’ve written using a timer or on a certain action. [import]uid: 6317 topic_id: 914 reply_id: 2132[/import]

[Abica]

The way I handle that exact problem is with a table of lines of text, such as:

local text = {  
 "line1",  
 "line2",  
 "line3",  
 "line4",  
 "line5",  
 "line6",  
 "line7"  
}  
text.index = 1  
[/code][code]  
local textLabel = display.newText(text[text.index], 0, 0, nil, 40)  
textLabel:setTextColor(255, 255, 255)  
textLabel.x = display.stageWidth / 2  
textLabel.y = display.stageHeight / 2  
[/code][code]  
timer.performWithDelay(3000, function()  
 transition.to(textLabel, {time=1000, alpha=1, onComplete=function()  
 transition.to(textLabel, {alpha=0, time=1000})  
 end})  
 text.index = text.index + 1  
 if text.index \> #text then  
 text.index = 1  
 end  
 textLabel.text = text[text.index]  
end)  

Obviously you can stick those into functions and simply call them. I tend to heavily use tables as namespaces. Like a collection of methods you can call at any time. Another technique is to implement classes with metatables. Both are pretty simple. [import]uid: 70 topic_id: 914 reply_id: 2133[/import]

[Abica]

Sorry, ignore the code in my last post. I was rushing out of the house to the airport to pick up in-laws and I hit enter on accident with in progress code, then wasn’t able to fix it until I got here due to lack of wifi.

This code better illustrates what I meant:

local linesOfText = { "line1", "line2", "line3", "line4", "line5", "line6", "line7" } linesOfText.index = 1 local textLabel = display.newText(linesOfText[linesOfText.index], 0, 0, nil, 40) textLabel:setTextColor(255, 255, 255) textLabel.x = display.stageWidth / 2 textLabel.y = display.stageHeight / 2 textLabel.alpha = 0 local fadeToNext = function(obj, t) t.index = t.index or 1 transition.to(obj, {time=1000, alpha=1, onComplete=function() transition.to(obj, {delay=1000, alpha=0, time=1000, onComplete=function() t.index = t.index + 1 if t.index \> #t then t.index = 1 end obj.text = t[t.index] end}) end}) end local fadeBetweenText = function(obj, t) fadeToNext(obj, t) timer.performWithDelay(3000, function() fadeToNext(obj, t) end, 0) end fadeBetweenText(textLabel, linesOfText) [import]uid: 70 topic_id: 914 reply_id: 2135[/import]

[fpassa]

Hi,

I don’t know if that method is the best one, because of intensive use of transition.to inside the same code-block. In fact, the code is executed but transition are pending, because of delay and time parameters. That will affect your fps response if you try it many times with long delays, because transition will be in a pile taking resources from your device.

Probably you will see that it works fine on simulator, but if you test that code in a real device, may be you can encounter a terrible response. Take into account that transition.to effects take new thread inside CORONA engine and again, they will not be release until they finish. So, at this point, you will have to consider to make it manually using a time or frame based animation to change you alpha between 0 to 1 or reverse.

But as you question was related to dinamic calling of methods, the answer about using parameters inside a function call is the best way for sure. The use of table…mmm well again, tables have a heavy cost in memory, but of course it depends on how much data you have to store there.

And my last recommendation would be to nil every object not needed before to use a next one. This will keep your memory with a little more room to apply effects.

For additional information try to obtain the LUA 5.1 programming manual or some book related to handle LUA code, as the CORONA programming reference.

Flavio. [import]uid: 3022 topic_id: 914 reply_id: 2141[/import]

[Abica]

Hi Flavio,

I’m not sure I understand how using sequential transitions with an infinite delay is as bad as you’re saying it is. There is no reason that that method couldn’t be implemented in a sequential fashion. Since the code is time based you’re essentially creating a new thread for a transition every 1 second. Before that thread finishes it’ll run it’s callback which starts a new thread.

The old thread should be considered dead and get collected next gc. Is that not the case? There’s no reason the last iteration of transition should still exist. The function frame will no longer have any references to it and should therefore get cleaned up by lua. The roughly equivalent memory will be allocated in it’s place when the next thread starts. So aside from the calling long running initial time delay thread, there should be no more than possibly 2 transition threads overlapping at any time for the above algorithm. Therefore the ephemeral memory should be negligible, right? Are you suggesting that those threads could be put to better used if they were handling more work?

I’ve tested methods like this on several devices under various loads and I haven’t observed any noticeable performance degradation.

• Nick [import]uid: 70 topic_id: 914 reply_id: 2152[/import]

[MikeHart]

>>The old thread should be considered dead and get collected next gc. Is that not the case?

I have a feeling that these dead thread are still exist. See my bug post about using transition.to slows down the framerate. [import]uid: 5712 topic_id: 914 reply_id: 2154[/import]

[Abica]

That’s really interesting. This looks to me like a memory leak. I can’t think of any technical reason why this should be the expected behavior.

I did notice that it’s far less obvious with the alpha transitions than it is with the x, y ones. I’ve been running these transitions on single display groups as opposed to large numbers of sprites directly. That is instead of creating 30 transitions for 30 sprites I create 1 transition for a group of 30 sprites.

Obviously if there is a leak it’d be very difficult to observe, even at large numbers of sprites in a group when using that method, so maybe it only appears to be more stable because of the much slower rate of the leak.

In fact with the single group method I still haven’t seen any slow down at all, even with the number of sprites cranked up to 100. [import]uid: 70 topic_id: 914 reply_id: 2160[/import]