Re: [tuxracer-devel] Greetings, and a question.
Status: Beta
Brought to you by:
jfpatry
From: Steve B. <sjb...@ai...> - 2000-03-26 06:04:40
|
Jasmin Patry wrote: > I've had a look at gltron > and it seems to be very easy to use SDL_mixer to play music. The > quality is excellent too. It uses pthreads so no explicit updates > are necessary, which should solve the problems reported by Steve with > libmikmod. To the contrary - glTron is the game I have most trouble with. When the audio is turned on, the frame rate (on even a static scene) jumps from better-than-60Hz to worse-than-5Hz about once a second - making the game utterly unplayable. It doesn't do this on all machines - which is strange. (The following comments apply to a single CPU machine) The thing is that putting a process into a second thread in no way assures that it'll run at appropriate times. You are at the mercy of the kernel's scheduler - which isn't really designed for realtime stuff. If your main renderer is at higher priority than the music thread then it'll run until it chooses to give up the CPU or until it runs out of it's timeslot. This can result in the music thread not running often enough - so the sound breaks up. If the music thread is at highest priority then it may run at inappropriate times causing it to swallow large chunks of time in one go - causing the video to hesitate at odd times. If they are at the same priority - then you may well see both of the above happening at different times. The solution is clear. You need your own scheduler to ensure that all processes get a fair chunk of the CPU every frame. You need each thread to voluntarily use only it's fair share of time - and to give back time often enough to let the other process run smoothly. Once you do that, you don't need the other thread...you might as well mung them together. Also, if you rely on the kernel scheduler, you can wave goodbye to portability. Linux's kernel might work OK - but what about Win95/98/NT/2k? Even within one OS, you'll get wildly different results with different sound cards - and with CPU's of differing speeds. This makes life impossible for the amateur developer who can't possibly test on a full range of systems. ...all of which brings us back to the problem with MikMod - which is that it doesn't give you control of how much time it consumes - and when. Even when running in a separate thread, it can get you into the kind of trouble that glTron has on my son's PC (but not on mine or the author's). So - my own sound library is deliberately designed to play nicely with 3D rendering by letting you tell it how often you intend to call it (and by implication, how much sound you want it to compute in each iteration). SL doesn't require a separate thread (and wouldn't work as well if it had one). > I've written Andreas to get some more info but the case for > SDL looks pretty strong. Well, I talk with Andreas quite a bit - he never did track down the sound problems with glTron on my kid's PC. > > If you'd like to hear the music I've written so far, I can put it up > > somewhere. > > Sure, that would be great! If they're not too large (under 1-2 MB) you can > just email them to me directly if that's easier for you. MOD files are rarely more than a few 10's of Kb - compactness is one of their great attractions. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |