> 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.
Seperate threads for emulation logic and sound generation isn't feasable for this projct, simply because the sound is generated from the emulation logic (running the emulator for 1 frame produces 1/60th of a second's worth of sound, for example -- it's not like I'm playing fixed sound files like wavs or whatever). Also -- ideally, the framerate of the emu is to be throttled by the sound output. The NES actually runs at a somewhat awkward 60.1 Hz... and produces a fixed amount of audio samples each frame. If I am drawing 60 frames every second and outputting 60.1/60 seconds worth of audio samples every second.. then my audio buffers will eventually overflow. Trimming or inserting samples to balance the audio output to match the framerate is an option -- however that distorts sound in several games (the NES allows games to stream PCM with timed writes -- if you mess with the timing the sound effect being streamed can be distorted or riddled with cracks and pops). So seperating my audio generation and main emulator logic into two seperate threads wouldn't be much help. However... buffering the generated audio and streaming it in another thread is certainly doable, and desirable despite it adding a bit of latency. But that's something usually handled by the audio library (I'm quite sure both SDL and FMod maintain their own threads for audio streaming)... so that'll be automated for me regardless. Creating a seperate thread to put the emulation logic in (to seperate it from the thread handling FLTK and its messages) is certainly an option. I didn't really consider it before, but maybe it would be the right way to go in this case. I'll have to experiment a bit with some test programs. > I believe Fl::wait(secs) will effectively 'sleep', while > keeping the interface alive, where secs is floating point. interesting @ Fl::wait. I'll have to try that out. I've done all this work in 1 thread before in my WinAPI version -- and have seen that the hang caused by sleeping isn't significant when done in small chunks (I'll be clearing the event queue between every frame). If the GUI takes a whole 1/50th of a second to respond to your mouse click -- I doubt the user will notice (I never have). I want to avoid OS specific stuff as much as possible -- creating threads is no exception. Burying my code in a nest of #ifdefs is unpleasant -- that's what crossplatform libraries are for (IMO). As far as sleeping goes -- I'm currently planning on trying to use SDL for gamepad support, and it has it's own sleep function I can use. Thread creation, however, isn't covered. If I'm going to go that route I may have to make my own wrapper. I have a tendacy to ramble on about this stuff. Heh Anyway -- thanks a bunch. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
