Disch wrote:
> 1) regarding the message pump. It appears the program forfeits control over
> to FLTK as soon as it calls Fl::run(), and programs can catch idle events to
> update itself between events. However pages clearly indicate that the timing
> for idle events is not something that can be relied on. I get the distinct
> impression that if I were to use idle events to drive my emulator, the
> framerate would be jerky and the sound would either drop out, or require
> crazy high latency.
> Needless to say, that is unacceptable for this paticular project. So I'm
> wondering if there is any way to get around this paticular issue. Ideally,
> I'd like it if you could retain control of the program and simply poll FLTK
> to empty its event queue every so often (like between every frame)
(Just adding some info to the other posts here)
As others have written, you probably want either Fl::check(),
or possibly better Fl::wait() in a loop, instead of calling Fl::run().
Or at very least, calling Fl::run() until you actually
need to manage audio servicing, then inside your audio loop,
call Fl::check() or Fl::wait() to keep the interface alive.
Either that, or use threads, or separate processes to manage
the audio, using either pipes or IPC to communicate between
the FLTK program and the audio managing process.
Threads would probably work well, as you could make a very
simple interaction between the main and audio threads, eg.
for getting the current playback point and setting it,
and being able to start/stop the audio playback.
> 2) Assuming #1 works out, I will need to be able to sleep.
I believe Fl::wait(secs) will effectively 'sleep', while
keeping the interface alive, where secs is floating point.
Of course you can always call the OS's sleep/msleep functions,
but that would hang up the interface if you run it in the main
thread.
Your app sure sounds like a case for using threads, but you
might be able to pull it off without them, since probably
none of the audio calls you're making wait very long.
> I didn't immediately notice any function to make the program sleep
> for X milliseconds.
Fl::wait() takes an optional argument in floating point seconds.
> One post I saw on this board had some example code that called
> system() to sleep, but I don't like that idea at all.
There is no reason you can't call the OS's own C library
sleep(3)/usleep(3) (unix) calls, or Sleep() in Windows.
Just beware if that's done in the FLTK thread, it will
hang up the interface.. better to use Fl::wait(secs).
> 3) I didn't see anything for joypad/gamepad support mentioned in the docs I
> skimmed. This isn't really that big of a deal since I can probably get that
> from another library... but it's worth asking about here. If this library
> can do it, no sense in adding another unecessary library.
I'm pretty sure the OS's own functions can be used.
IIRC this came up a year or so ago on the group,
and some details were discussed. Check the fltk.general
archive.. not sure what the subject is though.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
