Sam wrote:
What you have in bomberman is busy waiting. If you wanted to wait
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.
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 :^).
If I’m misunderstanding something regarding threads and busy waiting, I’d
like to know it…
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…
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).
-Dave
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