Does anyone know the sequence of the component parts of Codea. I know the general outline is setup(), draw(), touch() but there are other things like orientation of the iPad, sound etc. What order are they all run in, particularily now that we also have update() in Codea Craft.
My interest - I’d like to know how parameters fit in, they must be parsed. I have a project which uses them and which also prints() data to the output window. The printed output flickers and I’d like to stop that. The project is currently running at 50 fps.
@Bri_G Probably only TLL knows the order of everything. I would say that the majority of things are run/checked at 60 times per second by Codea. Things like touch, which are controlled by the operating system, are outside of Codea and buffered and then checked by Codea probably in the 60 fps loop. I’m assuming you’re doing output.clear() before printing. The flickering is probably caused because the display of the print window isn’t fully in sync with the print() statement. Sometimes when the output window is trying to display something, the output is cleared, but the print hasn’t happened yet. I don’t think you can clear the window and print something without flickering. I don’t normally use the print window for a fully running program.
@dave1707 - yeah used output.clear(). Also used a parameter.action which calls a function which is graphically extensive, my thoughts
were if the call is made from the parameter in the dystem loopbit may be starting the graphics routines.
@Bri_G This might be easier. Just set up a function to do your printing and put a counter in it so you only print every so often. It still flickers when it does the clear, but I don’t know if there’s a way around that yet.
EDIT: The fewer print statements you have, the less it flickers. If you have a lot to print, maybe you can format it so 1 print statement prints it all.
function setup()
cnt=90
end
function draw()
background(0)
prt()
text(1/DeltaTime,WIDTH/2,HEIGHT-50)
end
function prt()
cnt=cnt+1
if cnt<90 then
return
end
output.clear()
print("qwertyuiop")
print("asdfghjkl")
print("zxcvbnm")
cnt=0
end
@dave1707 - thanks for the suggestion, that’s more or less what I was doing, using the print() function to print a status report on variables to confirm what was happening. Took it a step further and combined all print statements into a string, flickered less but still annoying. Could deal with some of output with parameter.watch() but just concerned changes in Codea were affecting output.
Thought may be related to the windowing effect of the current version, perhaps all output is now addressed to an output window as against a screen.
Not worth further digging as it’s only used during development.
@dave1707 is right that things like orientation changes and touches are triggered by the OS and then scheduled to run in sync with the rendering loop.
This is how it generally works when you press play:
dependancies are run in the order they appear
tabs are run in the order they appear
the first time the screen is drawn setup() is run
draw() is called for the first time
wait for vsync
draw() is called at 60fps (or whatever rate it can handle)
After this any time an OS level event occurs such as a touch, screen orientation change, etc, these are scheduled to run on the OpenGL thread which may cause them to run either before or after the next draw call. This is done so that neither code, nor events can cause the UI or Codea to cease up.
The update() function itself is just a regular lua function. The scene:update(dt) method is what you described (convenient way of updating the state of a scene). This means you can have multiple scenes and update them in different ways (or not at all).