I have a few questions about the cycle time of Codea.
I think Simeon can answer my questions.
I have programmed four classes with the following functions; a PID controller, an Integrator, a First Order filter and an X-Y table.
I call these functions in main:draw().
The functions are working correctly.
The integration times are exactly as they should be.
I use “delta time” inside the calculations of the integration and differential time settings.
DeltaTime I present also with “watch” (updated after each second)
Delta time is between my program (approximately) 16.65 and 17.57 ms.
Question 1
I read in the forum and in the documentation that main:draw() will be called every 30 Th. of a second is. (iPad1)
That is not every 16.66 ms. What’s wrong?
Question 2
Suppose that the program takes longer than (about) 6.6 ms. Will main:draw() first completely finished before the next interrupt will restart main:draw() (i.e. x times 16.66 ms)?
Or will main: draw() by itself interrupted? Then something will be wrong, I think.
Question 3
Why require print() as much cycle time? What is happening here in relation to question 2
Sorry for my English. It is strange; I travelled a lot over the world for the offshore industry, I programmed control systems for offshore Big Cranes and control systems forr Tensioners and Winches for Pipe Lay Barges (Siemens S7 PLC system) (SCL programming language, based on Pascal)
I am retired now !!
Draw() is simply the main loop - when it exits, codea does some housekeeping then calls it again. So, frequency depends very much on how much you do in it - if you do less work, you’ll get called more often.
Print() is broken - it appears if you get a large console buffer it gets increasingly slow.
Ruilov, thank you for your info, 16 ms seems to be correct.
Yes, I have seen your game before, thank you very much!
Bortels, thank you, this means that if the cycle time of draw() longer then 16 ms it will be restarted after the next interrupt (call)
Print() is broken - ? This means that print will be interrupted by the next call of draw()? and that therefore the print buffer will be filled with the next print command, etc?
Okay Bortels, thanks for your replay.
What would be the reason that print slows the cycle time? Is it the print command itself?
But why? If I made a program with al lot of rectangles and circles with a lot of colours (etc) the cycle time will be (about) the same. It is not really importent, but just as knowledge.
My guess is that the print window itself is internally trying to determine how to draw and rebuffer itself each frame for quick scrolling. When you think of drawing text, that is a lot of work. A setting or component is needed that has a state of “add this to the list but don’t figure out how to render it” along with a “ok, now buffer and render”
I was thinking of a similar issue I has a few decades back in Visual Basic. I was using a selector box (like a drop down box, but no drop down, just a scrollbar. It contains an array of string that are selectable and had an index. It was built-in.). I had the same issue of this built-in being a hog. Not sure what I did to solve it but I wanted it there for what the users needed to do. I think what I did was use two components, one that was display only, the other that was scrollable/selectable. It would switch between the states. There was a noticeable lag in switching but it removed the lag from adding to it each time there was a new bit of data. I may have really had both and just flipped there visible property.
Anyway, if the community accepts…
Would it be OK if the print box during execution by default was a fixed tex box with no scrolling nor select/copy?
Then if you click on it, there is a long lag while it switches back to the scrollable version?
By default it should reset if the program is UNpaused (as in you pause then play) or the restart.
@hartland draw() will never be interrupted, but I am unsure if the cycle time will align to a particular frame rate. Internally, Codea makes use of Apple’s CADisplayLink timer to refresh the display and call the Main draw() function. It appears to just call draw() at the next available opportunity if too much work is done in one frame.
You’re right that there’s a documentation mistake - draw() is called every 60th of a second. The attempted frame rate is 60 frames per second, if possible.
@lpda41001 - nope! Right now, select-copy from print()ed data is the only way you have to export the results of a program run, other than re-typing it.
They should simply fix (or replace) print(). I doubt very much there’s a deep architectural issue - I think they just have a bug somewhere. print() during execution should be cheap - it’s just appending to a buffer.
Simeon, thank you.
My measurement cycle time is correct. Draw () is not interrupted. If draw() is longer than 16.66 ms then draw() will be called the next frame tick. DeltaTime will measured that, my time calculations will be correct then.
Variables used for testing I always use watch(). Why watch() it fast?
Simeon, I’ve read that in 1.3 the keyboard input and print text at location will be implemented. For my simulations, I really needed that! Thanks for the quick response!
Greetings, Dirk.nl
Hi Blanchot,
I will use Codea for programming control systems and arithmetics. To check a technical problem, in other words, to see whether a given control system to work properly (and responds on the right way) Therefore I must program the control system itself and the process.
Control systems will mainly consist of PID controllers, Integrators, Filters, Function tables, arithmetics, etc.
I have these function already programmed and tested, therefore my cycle time questions.
The process I will arrange to mathematically (and/or controlling) determine, there lies my problem, I’ll have to figure it out quietly.
With Codea I can make good use of calculations, making bar graphs, touch buttons to release and to test the influence of control, etc.
For this reason, I must have the possibility (during run time) to enter numbers from the keyboard and the possibility to present text and numbers on the screen. This will be added in version 1.3.
Blanchot, I have a lot to figure out, have been retired one year ago, so plenty of time and nice to do.