Thanks Mike, I understand the FPS adjustment, but I don’t necessarily want/need the overhead associated with updating the screen more often.
I understand how coroutines work, as well as the multithreading limitations of LUA (technically, I believe coroutines are a form of multithreading, just not *parallel* multithreading).
So in general, what I’m playing with is a coroutine dispatcher so that I can arbitrarily activate any number of “background threads”, and the dispatcher will handle the repeated calls to “resume” each thread as needed until they are complete. When I want to perform some background task, I can simply register the function to perform with this dispatcher, and the dispatcher can handle the rest.
The dispatcher mechanism itself is fairly trivial, and I’ve got one built already. The trouble is in how often the dispatcher itself has a chance to iterate through any active coroutines to give each coroutine a chance to execute.
The dispatch iteration itself needs to be continuous but interruptable, in order to process the coroutines as quickly as possible but still allow other code (and screen updates, etc.) to execute as needed. A tight loop won’t work, as no other code would get a chance to run.
Which is why I was trying a timer event, in an attempt to have my coroutine iteration execute continuously but allow as much time as possible to run the active coroutines. I figured if I ask for the dispatcher to fire every millisecond (not expecting to actually achieve that, of course, but to get the events as quickly as possible) then I could run more-or-less continuously while still allowing screen updates and other events to process as needed. Not necessarily an optimal solution, but theoretically it should work as a starting point for development at least.
Given my observations about how the timer mechanism seems to be working, I’ve already tweaked my dispatcher to loop through my active coroutines as much as possible, up to a set number of elapsed milliseconds, at which point the dispatcher stops until the next time it’s called. I could then trigger my dispatcher with either a timer or at the exit of each frame (which seems like a better solution than the timer). As I mentioned in my original post, that approach seems to work, but it’s a bit of a kludge to me because I’d have to specify that I want coroutines to execute for X milliseconds on each frame, when what I really want is for coroutines to be able to execute as much as they need to between frames. [import]uid: 8836 topic_id: 2045 reply_id: 6011[/import]
