[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pygame] diff betn interactive and non-interactive scripts
Pete,
I agree - this should defintely be kept for use in newbie
documentation..
On Wed, 2002-04-10 at 05:51, Pete Shinners wrote:
> Prahlad Vaidyanathan wrote:
> > Amazingly, that works !
> >
> > I basically now check the total time of the song, and then put in a
> > time.sleep() for that long.
> >
> > This is *seriously* weird from where I stand. Could someone explain why
> > this happens ?
>
> prahlad, here's what's going on.
>
> when your pygame program exits, all the pygame devices are shut down.
> this means the graphics are closed, the cdrom stopped, etc, and (what's
> getting you) the audio stops.
>
> when you call music.play() the music actually starts playing in a
> background thread. this means the play() function returns immediately
> and starts playing the song. this is the same for other types of Sound
> effects too (and the Movies work like this also).
>
> what you are probably 'expecting' is that the play() function doesn't
> return until the song is over. this behaviour is called "blocking",
> which means the function doesn't return until it is finished. the music
> play() function is "non-blocking", which means it returns immediately,
> before the work you ask for is finished.
>
> this "blocking" and "non-blocking" behavior is fairly common for many
> types of libraries. when reading from a file or networking device, there
> are usually blocking and non-blocking ways to do it. another big example
> is something like opengl. all the drawing functions of opengl are
> non-blocking. so when you call your opengl function to draw 10,000
> polygons, the draw function returns immediately, and the graphic card
> starts working on it's 10,000 polygons separate from your program.
> (hopefully that all makes a bit of sense)
>
> if you think about it. this non-blocking behavior is exactly what you'd
> want for games. if it was a blocking type of function, how would the
> game actually do anything while the music starts playing?
>
> since the music runs on its own, there's a couple methods of keeping
> track of what the music is doing. the first is simply music.get_busy(),
> which returns true or false, depending if there is any music playing or
> not. there is also an advanced tool, music.set_endevent(), which will
> place any event on the pygame event queue when the music has finished
> playing.
>
> in the development version of pygame, there is also a new advanced
> function, music.get_pos(). this tells you how long the music has been
> playing. (it may not seem so advanced, but internally it's a little
> tricky, it keeps exact track of SDL_mixer's progress on the song, so it
> properly takes into account any skips or jumps) (thanks micheal!)
>
> you mentioned this all worked differently between 'interactive' and
> 'scripted' python. perhaps it will be a little clearer if you go back to
> the interactive python session. initialize pygame and load up the music.
> then call the pygame.music.play(). notice how the music starts playing,
> but the interactive prompt returns immediately. you can now do anything
> else you want to in the interactive python shell, the music plays on its
> own. you can find out what the squareroot of 7 is, or call
> music.get_busy() to check on it's status. but most importantly, if this
> was a real game, you could move sprites around, check on user input, and
> draw exciting graphics. all while the music is playing along.
>
> now, before the music has finished, quit the python interpreter. notice
> how the music stops when the python interpreter stops? this is the same
> "problem" you are seeing when you play the music from a python script.
> once the program finishes, so does the music.
>
> what you need to do is keep the program running until the music has
> finished. there is a perfect example of this already in the pygame
> examples directory. take a look at "sound.py", and see how it
> 'verbosely' doesn't finish the program until the music has stopped.
>
> there are other methods to keep the program running, but this is likely
> the simplest.
>
>
> whoof, that came out pretty long, i should html'ize it and put it up as
> a new pygame introduction :] hopefully now you can 'understand' what
> exactly is going on, and why it happens.
>
>
> ____________________________________
> pygame mailing list
> pygame-users@seul.org
> http://pygame.seul.org
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org