@SteeveNoob tell me when you are done.
Thank you, I shall study it very carefully and hope to spot it 
I’m so dim, I have spent 20 mins staring at it and going through it step by step in my mind but I cannot see the problem.
Ok so you’earn the right for a hand!
You wrote:
For cnt=1,3 do…
So first cnt==1 then you draw a blue sprite.
Then cnt==2 then you draw a green sprite ON TOP OF IT so now it is green.
Then cnt==3 then you draw an orange sprite ON TOP OF IT so now it is orange.
You draw them all in a row at the same location, and they are opaque => you see last ne only.
Oh and the screen is updated all in one pass at each draw call, so you cant see intermediate drawing, you just see the final result of the draw()
Oh heck… That is a problem, it never occurred to me.
Well I can’t fathom out how to draw just one sprite and then change to the next so I’ll abandon that little project and go back to printing out Ignatz books, only 62 pages to print now 
But what do you want your program to do exactly?
Maybe you wanted to do that? Here the color alternate between each draw
-- Test 1
-- Use this function to perform your initial setup
function setup()
print("Sprite Test")
background(40,40,50)
backingMode(RETAINED)
parameter.action("Clear Screen", function() background (40,40,50) end )
cnt = 1
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
-- This sets the line thickness
-- Do your drawing here
if cnt==1 then spr="Planet Cute:Gem Blue" ; cnt=2
elseif cnt==2 then spr="Planet Cute:Gem Green" ; cnt=3
elseif cnt==3 then spr="Planet Cute:Gem Orange" ; cnt=1
end
sprite(spr,CurrentTouch.x,CurrentTouch.y)
end
note the parameter.action in the setup, not in the draw()
That works and yes, its what I wanted to do… cycle through the sprites.
Your ‘if’ statement seems a lot more complex than mine but it works so I guess thats the correct way to do it. I hope to learn something from this.
Thank you!
Edit!! I see! you got rid of the ‘for…’ loop and used a simpler method… ahh yes!
finally the penny drops and I understand it!
(although my mind still doesn’t understand why mine didn’t work, I guess my brain is still thinking in Basic, but that doesn’t matter, your method is far better and works!)
Thank you for your time once again!
Hi, @SteveNoob. Everyone else is donating some code to you, here’s mine.
-- Test 1
-- Use this function to perform your initial setup
function setup()
print("Sprite Test")
backingMode(RETAINED)
parameter.action("Clear Screen", reset)
cnt = 1
end
function reset()
cnt = cnt + 1
if cnt > 3 then cnt = 1 end
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
-- This sets the line thickness
-- Do your drawing here
background(40,40,50)
if cnt==1 then spr="Planet Cute:Gem Blue"
elseif cnt==2 then spr="Planet Cute:Gem Green"
elseif cnt==3 then spr="Planet Cute:Gem Orange"
end
sprite(spr,CurrentTouch.x,CurrentTouch.y)
end
Something to be clear about is how Codea operates. It looks roughly like this:
load tabs left to right
call setup() once
every 1/60th second
call draw()
call touched()*
call parameter callbacks*
end
* = optional--only called when you've touched the screen or
changed a parameter
Note it doesn’t matter what tab setup(), draw(), touched(), or the callbacks
are defined in, they get called after all the code in the tabs is loaded.
setup() is called first and just once, so it’s a great place to initialize your code.
Then draw() is guaranteed to get called–repeatedly–60x a second.
(Sometimes if you cram too much stuff into draw(), it’ll need to take
longer than 1/60 sec, in which case drawing speed slows down.
But as a beginner this won’t be a problem for some time.)
If you touch the screen, Codea waits until after the current draw()
finishes, then it interjects touched(). It also updates the CurrentTouch
global variable with the touch point’s screen location. Because of this,
we can dispense with writing touched() and instead get the location directly.
Here’s a summary of what my program does. The first (blue) sprite is shown,
and you can drag it around the screen. When you click the “Clear Screen”
button, the next (green) sprite appears and you can drag it. Click the
button again, the next (orange) sprite appears. Then the cycle repeats.
We’re going to treat the screen like an artist’s canvas–it starts out blank
and you paint on it for awhile. You decide you don’t like it, you gesso it
over and begin again. The difference with Codea is that you have to paint
every 1/60th second whether you want to or not, so that has to be considered.
In setup() the “backingMode(RETAINED)” says we’re going to keep adding
to the canvas (screen) every 1/60th sec–in other words, don’t erase
anything unless we say so. (So to switch sprites, we have to clear the screen
of the old sprite before we put the new one on. Some systems may
have a command to erase just the sprite, but Codea prefers the brute-force
tactic of erasing everything. That certainly erases the sprite, but then
you have to redraw everything else in order to get the screen back to the
way it was.)
Since we have 3 sprites, we count them, starting “cnt” at 1.
The first time Codea calls draw(), we clear the screen by setting the background
to a near-black. Then “cnt” is used to pick a sprite name, and finally
we draw it on the screen at the place you’re touching on the screen.
So far, so good, our first 1/60th second timeslice is done.
Now it’s 2/60th second and draw() is called again. What do we do?
Sometimes you do want to do things differently, but here we were crafty.
We can actually do again at 2/60 what we did at 1/60: erase the screen,
draw the sprite at the touch location. This happens so fast that the
human eye can’t perceive that the screen went blank. This is the underlying
basis for animation: draw in one place, erase it, draw it again in a nearby
place–do it quickly enough and you get smooth motion.
It’s not very exciting watching the sprite just sit there. So touch the
screen and drag it around. Let’s say you touched the screen just before 3/60.
Codea updates CurrentTouch with your touch point coordinates and then
calls draw() again. Erase the screen like before, but now the sprite gets
moved to the touch point. As you drag your finger, the sprite will
follow it like an obedient puppy.
When you press the “Clear Screen” button, the button callback function
“reset()” gets called once draw() has finished its current timeslice.
(We wrote it as a separate function to keep the parameter() statement short.)
You’ll note the callback does practically nothing: it just increments “cnt” and
makes sure it remains in the range 1…3. It doesn’t seem like much has
happened, has it?
But then draw() gets called again at 4/60. Your old sprite’s on the screen,
but setting the background black gets rid of it. The “if” statement
selects the second sprite and shows it in its place. (Since you touched the
button and not the screen, the last location of the old sprite matches
the first location of the new sprite, so it appears not to move and only
changes color.)
At this point everything in the program has been discussed. If I haven’t bored
you (or more likely everyone else) to tears, I hope you’ll find it useful.
I’ve tried to explain not just writing the code, but why the code is
written the way it is. I return you to your program now.
Thank you so much starblue!
I have to admit it took me a few re-readings of that to fully understand it!
at first I couldn’t understand when the reset function was called but then I saw it and the penny dropped.
I don’t quite understand what you mean by ‘tabs’ though.
‘loads tabs left to right’ - I don’t understand what that means what is a tab?
but the rest of it, I now understand and it has helped a huge amount, thank you for spending so much time doing that! much appreciated!
think of tabs as pages in a notebook, convenient for splitting your code into sensible chunks
you can add new tabs with the plus sign at top right of the editor. Codea doesn’t care which tab you put the code in, or what order the tabs are in.
you’re unlikely to need too many tabs early on, because you won’t have hundreds of lines of code.
Ahh that’s really nice to have.
Thank you
Tabs are what you see in Codea’s editor along the top. There’s always one named “Main” (it’s the one containing setup() and draw()), and you can define others. They’re there to help organize your program.
The computer doesn’t care whether your code sits in multiple tabs or just one tab; it can load and execute the code either way. But human beings find programs much easier to read and comprehend if they’re broken up into small, cohesive chunks. Codea provides with their app lots of great example programs that show this organizing principle in use. I’d look at some of them, but don’t read the code, just look at the tabs–see how other people organize things. See if you can get an idea of what a program does just by looking at the tab names. Then run it. For any command performed or objects drawn on the screen, see if you can figure out which tabs were likely involved in the action.
@starblue Sorry, I have two things to point out…
-
There’s no reason to call backingMode(RETAINED) if you call background() in draw, as background() will fill the screen with the specified color and restart drawing to a blank canvas as if backingMode(RETAINED) never existed. That function is only for if you want to save drawing from the previous frame, in which case background() is called in setup to only set the screen to a blank canvas once.
-
With Codea, drawing actually works a tiny bit differently than you said. The reason you don’t see the flicker between frames where everything is being redrawn isn’t because it goes too fast to see, it’s because… Picture that draw() is drawing everything to a hidden canvas. You don’t see the flicker because it doesn’t show the canvas until it’s done being painted. If you have a really laggy program, say, a lot of physics collisions, you can see each frame pass by, but not each physics object being drawn because of this. It’s smart here, but in some programming languages, such as Java, when you draw to the screen you actually can see each shape being drawn, and there is a flicker. (Thus came BufferedImages, but that’s some advanced Java stuff, not Lua.)
Hi @SkyTheCoder. What you say makes sense. Certainly for #1, the way I use draw() in my example, backingMode() could’ve been omitted. #2 is less obvious. I thought Codea just drew fast enough that you didn’t see it. (I haven’t written anything yet complicated enough to show a difference.) I’m familiar with the Java approach. Anyway, that’s useful to know, thanks.
To add to what SkyTheCoder says, the flicker that many people see in their Codea programs is not due to slow frame rate but due to the fact that Codea actually uses three image buffers to draw to the screen. So if you don’t blank them each time then there is a flicker as what is drawn on one doesn’t reappear until it loops round again in three frames time. It can be quite instructive to see this in action by drawing, say, an ellipse at different coordinates on different frames and seeing which appear when, but not for those who get migraines! (If you do do it, look out for slightly different behaviour with the first few frames.)
Also, on a very minor point:
The computer doesn’t care whether your code sits in multiple tabs or just one tab
is not quite right. Tabs are “chunks” and if you declare a variable local inside one tab then it won’t be available to other tabs.