[SDL] bomber busy waiting?

Sam Lantinga slouken at devolution.com
Mon Aug 2 00:31:39 PDT 1999


> As regards the sound stuff there is no busy waiting in my code, it is
> just the SDL audio callback that I wrote. At the start the code checks
> for audio commands and adds each requested audio sample to the list of
> active samples, then when there are no more commands in the queue, the
> code actually sums the commands and fills in the audio buffer. It doesn't
> wait until a command is received, it just deals with commands that are
> already there ready to be processed.

That's cool.  Make sure that another thread cannot update the list of
sound commands in a way that will cause the audio callback to break.
(Or use SDL_LockAudio()/SDL_UnlockAudio())

> In mainline code I think I busy wait to get the timer interrupt, forcing
> frame rate to 25 hz, but only under Win32. Under *nix I use the pause()
> function which waits until the next interrupt, but doesn't hog cpu cycles.
> I go that extra mile for linux :^).

Me too. :)

> Regarding the Blit example that could actually generate an error, I'd be
> satisfied if an illegal blit caused a core dump or otherwise massive
> failure. Speaking of clipping, I assume the lib routines will choke if I
> don't do clipping. So I do clipping myself. Now if the library also does
> clipping, it is a waste. Keep SDL thin and simple--if that means the programmer
> has to do more checking, that's fine. My programming style is to assume
> routines that I didn't write (IE system or library routines) will break
> on the slightest provocation. So I don't try to free() a null pointer
> just because it is convenient. And I always check the file handle on a
> file open to make sure it actually did open the file...

A very good practice.
SDL does indeed perform clipping on the blit (but not on the update), but
if you already clip the blitting routines, then you can use SDL_LowerBlit()
instead of SDL_BlitSurface(). :)

> Also regarding blitting, I didn't realize there was a blit function in SDL.
> That's good because later it could be implemented as hardware accelerated,
> (or maybe it already is).

Yep, it already is under some circumstances.

	-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software
--
"Any sufficiently advanced bug is indistinguishable from a feature"
						 -- Rich Kulawiec 



More information about the SDL mailing list