backingmode(RETAINED) bug

@Simeon Where is the proper place to put backingMode(RETAINED). Here’s some code I posted in another discussion about the RETAINED problem. If I run this code with RETAINED before setup(), I get the numbers 1 thru 20 displayed. If I put RETAINED in the setup() function, the number 1 doesn’t show.


displayMode(FULLSCREEN)
backingMode(RETAINED) -- when run, always shows the numbers 1 thru 20

function setup()
    --backingMode(RETAINED)   -- when run, doesnt show the number 1
    count=0
    fill(255)
end

function draw()
    if count<20 then
        count=count+1
        text(count,WIDTH/2,HEIGHT-count*30)
    end
end

@dave1707 if you need a permanent and immutable backing store in your project, I would suggest putting it in the global scope. If you need to switch between RETAINED and STANDARD while running, I would recommend the solution I posted above (I.e., it waits one draw cycle before kicking in, calling your initial drawing at the correct time).

I used the following code to fix the backingMode(RETAINED) problem in all of my projects. The code below also helps with other graphical glitches that occur in the first second after pressing the play button in the editor. :slight_smile:

function draw()

    if ElapsedTime > 0.5 then
       <insert all of your drawing code here>
    end

end

Here another way to do it. You can change _a to another variable name if you want to. But what I don’t like about this is the extra code that’s executed each draw cycle. By skipping the 1 draw cycle at the start, I didn’t loose any frames in the RETAINED testing I did. This isn’t needed if RETAINED is set before setup() starts, but is used when RETAINED is in setup().

function draw()

    if not _a then _a=true return end                -- skips 1 draw cycle
    
    --add drawing code here

end

@dave1707 Just combine that with your recent discovery about a function rewriting itself:

function draw()
    function draw()
        -- put all your drawing code here
    end
end

@LoopSpace That works and there isn’t the extra code thats needed to be executed in draw(). It might be a little confusing for someone that hasn’t seen the nested functions.

It’s a bit disenchanting when a newbie drops onto a system bug after a few hours experimenting with Codea.
Dave gave me a ‘backingMode(RETAINED)’ solution to my problem and looking into it I came across this thread. This forum has to be the most important supplement to the ‘manual’ even though most of it goes way over a newbies head.

@Steep what system bug are you referring to?

@Steep If you put backingMode(RETAINED) before setup(), then there isn’t a problem with it. If you put it within the setup() function, then the first and/or second draw isn’t retained. That requires at least 2 draw call to be ignored. Until it gets fixed, if in can be, you’ll have to work around it.

Simeon - http://codea.io/talk/discussion/comment/57152/#Comment_57152
As a relative newbie to Codea, Lua and the iPad I expect to code within the functions setup and draw. Debugging code is a problem in any event and where the solution involves calls outside those two functions it becomes a nightmare to newbies.
I use ‘bug’ as a general term for coding problems.

@Steep puting code outside setup and draw is weird for a newbee indeed, i remember i was there too. However, this is not weird at all for lua people. Check the web for lua, you’ll see tons of code. Codea is built on top of lua, so it is not going to narrow lua usage. So you’ll have to learn lua, but slowly is ok.
Oh, btw, codea is really almost bug free, compared to many other platforms! I really enjoy that, when there is a bug in my code, 99.9% of times it comes from me, not codea!

@Steep backingMode is a very special case. Either you can have it functioning in setup — but then the entire setup() function must be evaluated prior to drawing (so you can’t actually draw in setup).

This used to be the case in an older version of Codea, however many people preferred to have the ability to draw in the setup function, especially using setContext to pre-render images for use later.

Anything that touches how iOS is actually going to display your view prior to presenting it will not work immediately in setup(). I think only backingMode and supportedOrientations fit this description.

As a. newbie I can only describe that as a bug.
There are three possible causes. Me, my iPad, Codea or Lua.
I’m thankful for help that I get from this forum.