I've also been looking into doing something basically the same, whereby I execute a number of uninterrupted functions at the start of each frame, then there is some random amount of time left between those functions being completed and the end of the frame time arriving (as I need to do a Flip `on time`). What I wanted to do is, in the random amount of time at the end of each frame, keep executing a given function as many times `as possible` before the time runs out.
The only way I can see to do this, is to repeatedly call Millisecs() in a loop, calling the function once or a few times (if it's small), and then when Millisecs() gets to a certain point based on the start time of the frame I break out of it, do the Flip, then start with a new frame.
So basically I need a sort of multitasking system, where a certain piece of code (a function) is given x amount of time and is allowed to keep running for that long, then has to stop to allow other predetermined things to process on-time. But managing a `timeslice`, as in your case as well, ragtag, seems to be only possibly by constantly checking Millisecs(). I'm finding that this can produce quite a significant overhead. In fact, it can eat up more than 10 times the processing time compared with just excecuting the given function a predetermined number of times without timing it.
You may want to cut down your calls to Millisecs() as much as possible. Like, you don't need to say "If Millisecs()", and then when that If is satisfied go on to say "Start=Millisecs()". You may be better of saying "Milli=Millisecs()" outside the If statement, and then "If Milli>Start+Wait Then Start=Milli". That should speed it up quite a bit because, well, I don't know how efficiently Max looks at what the millisecs is, but I am guessing each time you call it it is doing some kind of memory/access/calculation to `go look` for the time, rather than have the o/s conveniently place changes in a buffer only when they occur, with the buffer then being polled more efficiently. In my case I cut out as many calls to Millisecs() as I could possibly do and this helped with how many function calls I could make. I guess it depends how big the chunks of code are that you call in the time you have.
I could not see a better or more efficient way to do this yet. The idea of using events and hooks sounds great, in the sense that you can then override whatever is happening the instant that the timer event occurs, so you don't have to keep looking at the timer to see its value or to test it. But then I'm not sure how that timer is being managed by the o/s. Does the o/s spend as much time polling the timer and then create the event, or is the timer in hardware that triggers some code only as an interrupt when it `counts down` to zero? That would be ideal. But then again, and correct me if I'm wrong, don't you have to have MaxGUI to use hooks and events like that?
For now I am continuing to just call Millisecs() lots of times inbetween executing small chunks of code, until available time is used up. It's not efficient and its a lot slower than regular untimed code, but it does work.
I thought about timing how long the excecuting piece of code takes to excecute, then calculate how many times it can approximately be called within a given time frame to use up the time, then just do a For/Next loop calling it x number of times - saving any need to check Millisecs(). But then, you have to test it at runtime and if you've got a lot of possible functions to execute that could be inconvenient. You can't really estimate execution time because there is so much different hardware. So I dunno. Keep working at it.
The only way I can see to do this, is to repeatedly call Millisecs() in a loop, calling the function once or a few times (if it's small), and then when Millisecs() gets to a certain point based on the start time of the frame I break out of it, do the Flip, then start with a new frame.
So basically I need a sort of multitasking system, where a certain piece of code (a function) is given x amount of time and is allowed to keep running for that long, then has to stop to allow other predetermined things to process on-time. But managing a `timeslice`, as in your case as well, ragtag, seems to be only possibly by constantly checking Millisecs(). I'm finding that this can produce quite a significant overhead. In fact, it can eat up more than 10 times the processing time compared with just excecuting the given function a predetermined number of times without timing it.
You may want to cut down your calls to Millisecs() as much as possible. Like, you don't need to say "If Millisecs()", and then when that If is satisfied go on to say "Start=Millisecs()". You may be better of saying "Milli=Millisecs()" outside the If statement, and then "If Milli>Start+Wait Then Start=Milli". That should speed it up quite a bit because, well, I don't know how efficiently Max looks at what the millisecs is, but I am guessing each time you call it it is doing some kind of memory/access/calculation to `go look` for the time, rather than have the o/s conveniently place changes in a buffer only when they occur, with the buffer then being polled more efficiently. In my case I cut out as many calls to Millisecs() as I could possibly do and this helped with how many function calls I could make. I guess it depends how big the chunks of code are that you call in the time you have.
I could not see a better or more efficient way to do this yet. The idea of using events and hooks sounds great, in the sense that you can then override whatever is happening the instant that the timer event occurs, so you don't have to keep looking at the timer to see its value or to test it. But then I'm not sure how that timer is being managed by the o/s. Does the o/s spend as much time polling the timer and then create the event, or is the timer in hardware that triggers some code only as an interrupt when it `counts down` to zero? That would be ideal. But then again, and correct me if I'm wrong, don't you have to have MaxGUI to use hooks and events like that?
For now I am continuing to just call Millisecs() lots of times inbetween executing small chunks of code, until available time is used up. It's not efficient and its a lot slower than regular untimed code, but it does work.
I thought about timing how long the excecuting piece of code takes to excecute, then calculate how many times it can approximately be called within a given time frame to use up the time, then just do a For/Next loop calling it x number of times - saving any need to check Millisecs(). But then, you have to test it at runtime and if you've got a lot of possible functions to execute that could be inconvenient. You can't really estimate execution time because there is so much different hardware. So I dunno. Keep working at it.