Are timers meant to be linked to the update() function?

Discostew

It was my understanding that the timers would interrupt executing the main code in order to process whatever function they were tied to. But, it seems timers are tied to the update() function, so if there's heavy CPU usage to the point where one can't use the update() upon regular intervals, the timers get affected as well. In fact, one can't have timer intervals beyond 60 times a second by this notion.

Discostew

Now I'm sure it's linked to update(). Tried my MML program using timers to update at 60 times a second like it would if I were to call the MML update manually prior to the update() function, and it worked as intended, but the moment I reduced the interval to be between 30 and 59 times a second, the playback drop to half rate. Then dropping between 20 and 29 times a second, it dropped to 1/3 rate.

Is this intentional?

Dave

Timers are not specifically tied to the frame rate, but frame rate will affect how often the timers are checked.

The timers won't trigger while Fuze is waiting for a vsync - they only trigger while the interpreter is running. If your code isn't doing very much, for eg:

loop
    clear()
    update()
repeat

Then, effectively it will be checking the timer once per frame.

It is intentional, yes.

Discostew

@Dave So technically, if one has a lot of processing, but can still maintain doing it all with 1 frame's worth of time, a timer can actually trigger more than once per frame. Just did a test with my program, forcing a high iteration for loop to push roughly 12ms per frame in the main loop, and set the timer interval to less than 1/60 of a second (tested with 1/300), and sure enough, it was triggering multiple times per frame. Right after the for loop though was the update() line, which would mean timers would stop slightly. I imagine the reason for designing timers this way is because someone might throw some graphical code into the timer function, or something of that nature that might interfere with the environment outside of the main program code?

Then maybe I can make a feature request? If by chance we get to have multiple timers (or still just the one), might we have the option per timer to limit certain functionality within the timer function, so as to not interfere with various aspects of FUZE? Like, if it's graphics that are the problem, then just ignore them? Truth be told, this all has to do with my MML Player (I've spoken of nothing else all this time), which is purely using audio functions along with time() to derive how much time has elapsed since the last trigger. Updates of 60 times a second do work, but the audio accuracy is certainly on the low end. It doesn't use much processing, but timing of playing notes goes off the less often it can check. Of course my wish is that it may be worthy enough to be ported/integrated into FUZE to run natively once completed, where it won't have these limitations to worry about.

Waiting for timers to be settable within functions for the time being as they currently give an error upon doing so. Setting timers in the global scope work though.

Dave

We're not planning to change how the timers work at this point. You can have multiple timers running at once however!

t1 = setTimer( interval, count, function() )
t2 = setTimer( interval, count, function() )

startTimer( t1 )
startTimer( t2 )
stopTimer( t1 )

// etc etc

Sincere apologies if the documentation hasn't made that clear enough. The fact that you can't set a timer within a function is indeed a bug which should be fixed.

Discostew

Well, hopefully it will be considered at some point. Things like update(), sleep(), etc that halt the interpreter will affect anything using timers unfortunately.