[pygame] Communicating with an event queue
Hello all, For the movie module, I need to be able to communicate with a process programmatically. The video player in discussion is ffplay(because its the smallest), and it has an internal event loop around the SDL event loop. When I use subprocess.Popen to open up the video player running a file, with the PIPE arguments to all std*'s, only the window spawned responds to commands from the keyboard, indicating that the event loop doesn't listen on stdin. Is there a way to cause events to be pushed onto the process's internal event loop? -Tyler -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Communicating with an event queue
Tyler Laing wrote: > For the movie module, I need to be able to communicate with a process > programmatically. > > The video player in discussion is ffplay(because its the smallest), and it > has an internal event loop around the SDL event loop. When I use > subprocess.Popen to open up the video player running a file, with the PIPE > arguments to all std*'s, only the window spawned responds to commands from > the keyboard, indicating that the event loop doesn't listen on stdin. > > Is there a way to cause events to be pushed onto the process's internal > event loop? I'm not sure what the question is? I may just be missing data due to unfamiliarity with the structure in question. Shouldn't you, as the developer, be able to insert a method into the movie subsystem wrapper object that takes a command and places it in queue to be processed by the subprocess' loop?
Re: [pygame] Communicating with an event queue
Well, the movie module will use different back ends. One back end is nearing alpha testing, the wrapper around ffmpeg. If that back end fails to load, then we want to load in a wrapper around a video player that will be distributed with pygame, and I'm trying to figure what needs to be done to get that working, and whether or not I'll need to customize its code myself. The wrapper would create a sub-process of the movie player, playing the video file given. When I communicate with the subprocess via a pipe through STDIN, it should theoretically be controllable. I'm just wondering if there's a way, from string input to stdin, to cause SDL to fire a keyboard event? I don't think there is, but I thought I'd double-check that. Its better to take the simple and robust way, if it exists, rather than customizing a program for the needs of the movie module, which it looks like I'll have to do. -Tyler On Thu, Jun 18, 2009 at 10:19 AM, NBarnes wrote: > Tyler Laing wrote: > > > For the movie module, I need to be able to communicate with a process > > programmatically. > > > > The video player in discussion is ffplay(because its the smallest), and > it > > has an internal event loop around the SDL event loop. When I use > > subprocess.Popen to open up the video player running a file, with the > PIPE > > arguments to all std*'s, only the window spawned responds to commands > from > > the keyboard, indicating that the event loop doesn't listen on stdin. > > > > Is there a way to cause events to be pushed onto the process's internal > > event loop? > > I'm not sure what the question is? I may just be missing data due to > unfamiliarity with the structure in question. Shouldn't you, as the > developer, be able to insert a method into the movie subsystem wrapper > object that takes a command and places it in queue to be processed by > the subprocess' loop? > -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Communicating with an event queue
Hi, you can send key events, but it is very platform specific. There might be a xplatform python package out there somewhere to send key events... but I'm not sure. Maybe it wouldn't be too hard to make a win/mac/X module yourself if one doesn't exist. Perhaps mplayer with slave mode would be a good one to start with? Here is the page which describes it's slave mode: http://web.njit.edu/all_topics/Prog_Lang_Docs/html/mplayer/#slave I'm sure you've noticed, but using communicate with subprocess can prevent hanging - compared to using stdin/stdout directly. cu, On Fri, Jun 19, 2009 at 3:44 AM, Tyler Laing wrote: > Well, the movie module will use different back ends. One back end is nearing > alpha testing, the wrapper around ffmpeg. If that back end fails to load, > then we want to load in a wrapper around a video player that will be > distributed with pygame, and I'm trying to figure what needs to be done to > get that working, and whether or not I'll need to customize its code myself. > The wrapper would create a sub-process of the movie player, playing the > video file given. When I communicate with the subprocess via a pipe through > STDIN, it should theoretically be controllable. I'm just wondering if > there's a way, from string input to stdin, to cause SDL to fire a keyboard > event? I don't think there is, but I thought I'd double-check that. Its > better to take the simple and robust way, if it exists, rather than > customizing a program for the needs of the movie module, which it looks like > I'll have to do. > > -Tyler > > On Thu, Jun 18, 2009 at 10:19 AM, NBarnes wrote: >> >> Tyler Laing wrote: >> >> > For the movie module, I need to be able to communicate with a process >> > programmatically. >> > >> > The video player in discussion is ffplay(because its the smallest), and >> > it >> > has an internal event loop around the SDL event loop. When I use >> > subprocess.Popen to open up the video player running a file, with the >> > PIPE >> > arguments to all std*'s, only the window spawned responds to commands >> > from >> > the keyboard, indicating that the event loop doesn't listen on stdin. >> > >> > Is there a way to cause events to be pushed onto the process's internal >> > event loop? >> >> I'm not sure what the question is? I may just be missing data due to >> unfamiliarity with the structure in question. Shouldn't you, as the >> developer, be able to insert a method into the movie subsystem wrapper >> object that takes a command and places it in queue to be processed by >> the subprocess' loop? > > > > -- > Visit my blog at http://oddco.ca/zeroth/zblog >
Re: [pygame] Communicating with an event queue
Unfortunately, no, communicate does not prevent hanging: http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate It says it waits for the subprocess to terminate :/ However, that mplayer slave mode looks awesome. How big would a statically compiled mplayer executable be? The windows download, with smplayer gui is 12.5 MB. Or should I create an mplayer backend that checks if mplayer has been installed? -Tyler On Thu, Jun 18, 2009 at 3:28 PM, René Dudfield wrote: > Hi, > > you can send key events, but it is very platform specific. There > might be a xplatform python package out there somewhere to send key > events... but I'm not sure. Maybe it wouldn't be too hard to make a > win/mac/X module yourself if one doesn't exist. > > Perhaps mplayer with slave mode would be a good one to start with? > Here is the page which describes it's slave mode: > http://web.njit.edu/all_topics/Prog_Lang_Docs/html/mplayer/#slave > > I'm sure you've noticed, but using communicate with subprocess can > prevent hanging - compared to using stdin/stdout directly. > > > cu, > > On Fri, Jun 19, 2009 at 3:44 AM, Tyler Laing wrote: > > Well, the movie module will use different back ends. One back end is > nearing > > alpha testing, the wrapper around ffmpeg. If that back end fails to load, > > then we want to load in a wrapper around a video player that will be > > distributed with pygame, and I'm trying to figure what needs to be done > to > > get that working, and whether or not I'll need to customize its code > myself. > > The wrapper would create a sub-process of the movie player, playing the > > video file given. When I communicate with the subprocess via a pipe > through > > STDIN, it should theoretically be controllable. I'm just wondering if > > there's a way, from string input to stdin, to cause SDL to fire a > keyboard > > event? I don't think there is, but I thought I'd double-check that. Its > > better to take the simple and robust way, if it exists, rather than > > customizing a program for the needs of the movie module, which it looks > like > > I'll have to do. > > > > -Tyler > > > > On Thu, Jun 18, 2009 at 10:19 AM, NBarnes wrote: > >> > >> Tyler Laing wrote: > >> > >> > For the movie module, I need to be able to communicate with a process > >> > programmatically. > >> > > >> > The video player in discussion is ffplay(because its the smallest), > and > >> > it > >> > has an internal event loop around the SDL event loop. When I use > >> > subprocess.Popen to open up the video player running a file, with the > >> > PIPE > >> > arguments to all std*'s, only the window spawned responds to commands > >> > from > >> > the keyboard, indicating that the event loop doesn't listen on stdin. > >> > > >> > Is there a way to cause events to be pushed onto the process's > internal > >> > event loop? > >> > >> I'm not sure what the question is? I may just be missing data due to > >> unfamiliarity with the structure in question. Shouldn't you, as the > >> developer, be able to insert a method into the movie subsystem wrapper > >> object that takes a command and places it in queue to be processed by > >> the subprocess' loop? > > > > > > > > -- > > Visit my blog at http://oddco.ca/zeroth/zblog > > > -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Communicating with an event queue
On Fri, Jun 19, 2009 at 8:37 AM, Tyler Laing wrote: > Unfortunately, no, communicate does not prevent hanging: > http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate > It says it waits for the subprocess to terminate :/ > > However, that mplayer slave mode looks awesome. How big would a statically > compiled mplayer executable be? The windows download, with smplayer gui is > 12.5 MB. Or should I create an mplayer backend that checks if mplayer has > been installed? > > -Tyler > yeah, it would be an if installed deal. VLC is probably more widely installed than mplayer... but not sure if it can do a slave mode too... but I think it should be possible. http://wiki.videolan.org/VLC_command-line_help VLC is also much more commonly installed xplatform, eg on windows/mac/linux
Re: [pygame] Communicating with an event queue
On Fri, Jun 19, 2009 at 10:14 AM, René Dudfield wrote: > On Fri, Jun 19, 2009 at 8:37 AM, Tyler Laing wrote: >> Unfortunately, no, communicate does not prevent hanging: >> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate >> It says it waits for the subprocess to terminate :/ >> >> However, that mplayer slave mode looks awesome. How big would a statically >> compiled mplayer executable be? The windows download, with smplayer gui is >> 12.5 MB. Or should I create an mplayer backend that checks if mplayer has >> been installed? >> >> -Tyler >> > > yeah, it would be an if installed deal. > > VLC is probably more widely installed than mplayer... but not sure if > it can do a slave mode too... but I think it should be possible. > http://wiki.videolan.org/VLC_command-line_help > > VLC is also much more commonly installed xplatform, eg on windows/mac/linux > This document describes it's control interfaces: http://www.videolan.org/doc/play-howto/en/ch04.html You can control it by http, which could be nice. Another method might be to read output from ffmpeg/vlc, and do the display/play audio in pygame. So you'd just read frames from stdin, and then play them back. This way might be simpler than assuming the window of VLC. cu,
Re: [pygame] Communicating with an event queue
Apparently there's a remote control interface. full play, pause, stop, seek, resize capabilities. If I can get the stuff from Marcus on redirecting screen output through pygame, then I can make an effective module. -Tyler On Thu, Jun 18, 2009 at 5:22 PM, René Dudfield wrote: > On Fri, Jun 19, 2009 at 10:14 AM, René Dudfield wrote: > > On Fri, Jun 19, 2009 at 8:37 AM, Tyler Laing wrote: > >> Unfortunately, no, communicate does not prevent hanging: > >> > http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate > >> It says it waits for the subprocess to terminate :/ > >> > >> However, that mplayer slave mode looks awesome. How big would a > statically > >> compiled mplayer executable be? The windows download, with smplayer gui > is > >> 12.5 MB. Or should I create an mplayer backend that checks if mplayer > has > >> been installed? > >> > >> -Tyler > >> > > > > yeah, it would be an if installed deal. > > > > VLC is probably more widely installed than mplayer... but not sure if > > it can do a slave mode too... but I think it should be possible. > > http://wiki.videolan.org/VLC_command-line_help > > > > VLC is also much more commonly installed xplatform, eg on > windows/mac/linux > > > > This document describes it's control interfaces: > http://www.videolan.org/doc/play-howto/en/ch04.html > > You can control it by http, which could be nice. > > > Another method might be to read output from ffmpeg/vlc, and do the > display/play audio in pygame. So you'd just read frames from stdin, > and then play them back. This way might be simpler than assuming the > window of VLC. > > > > cu, > -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Communicating with an event queue
On Fri, Jun 19, 2009 at 10:24 AM, Tyler Laing wrote: > Apparently there's a remote control interface. full play, pause, stop, seek, > resize capabilities. If I can get the stuff from Marcus on redirecting > screen output through pygame, then I can make an effective module. > > -Tyler SDL_WINDOWID allows you to do this. It allows you to init the SDL display using an existing window. It's a bit hacky, but can kind of work. mplayer also allows you to select an existing window to put itself into. However I think the 'frames over pipe' approach will have less issues - and probably be more portable. cu,
[pygame] physics engine?
hi, what 2d physics engine would you recommend for using with pygame? what happened to the SOC physics project? is it finished? will it be included in pygame?
Re: [pygame] physics engine?
On Fri, Jun 19, 2009 at 11:25 AM, machinim...@gmail.com wrote: > hi, > > what 2d physics engine would you recommend for using with pygame? > > what happened to the SOC physics project? is it finished? will it be > included in pygame? Unfortunately not much work has been done on that since the gsoc last year finished... and no one else has really picked it up. It lives in pgreloaded now. However I don't know of any games using it. Perhaps if it got some users and a maintainer it might improve. I think Marcus might have plans for it, but not sure what they are. Perhaps it might get into pygame 1.9.1... but definitely not 1.9.0. The main engines used by people are these two engines: pybox2d http://pygame.org/project/723/ http://code.google.com/p/pybox2d/ pymunk http://pygame.org/project/780/ http://code.google.com/p/pymunk/ There are a number of successful games using them - and both projects have people working on them, and they seem well maintained. There's also py-lepton, which is a particle library... which does some particle physics stuff, but not really a physics library: (no pygame project page) http://code.google.com/p/py-lepton/ and finally pyode - which is more complex, and seems harder for people to finish games with, but does 3d stuff: (no pygame project page) http://pyode.sourceforge.net/ Also have a look on the pygame website for physics stuff. There's some simple stuff in there, which might be nice to learn from. http://pygame.org/tags/physics cheers,
Re: [pygame] physics engine?
On 6/19/09, René Dudfield wrote: > > On Fri, Jun 19, 2009 at 11:25 AM, > machinim...@gmail.com wrote: > > hi, > > > > what 2d physics engine would you recommend for using with pygame? > > > > what happened to the SOC physics project? is it finished? will it be > > included in pygame? > > > Unfortunately not much work has been done on that since the gsoc last > year finished... and no one else has really picked it up. It lives in > pgreloaded now. However I don't know of any games using it. Perhaps > if it got some users and a maintainer it might improve. I think > Marcus might have plans for it, but not sure what they are. Perhaps > it might get into pygame 1.9.1... but definitely not 1.9.0. > > The main engines used by people are these two engines: > > pybox2d > http://pygame.org/project/723/ > http://code.google.com/p/pybox2d/ > > pymunk > http://pygame.org/project/780/ > http://code.google.com/p/pymunk/ thanks! i will look into these two and also into your other links... There are a number of successful games using them - and both projects > have people working on them, and they seem well maintained. > > > There's also py-lepton, which is a particle library... which does some > particle physics stuff, but not really a physics library: > (no pygame project page) > http://code.google.com/p/py-lepton/ > > and finally pyode - which is more complex, and seems harder for people > to finish games with, but does 3d stuff: > (no pygame project page) > http://pyode.sourceforge.net/ > > > Also have a look on the pygame website for physics stuff. There's > some simple stuff in there, which might be nice to learn from. > http://pygame.org/tags/physics > > > > cheers, >
[pygame] Time-based interpolation :: jitter problem
Hi ! I am trying to use an interpolation based on time.time() to create smooth animations with Pygame and OpenGL. The idea is to get time-based motion tween, instead of frame-based. It seems like there is still jitter in my interpolation. The motion is not uniform. Anyone can propose a more accurate way to measure time (human-perceived time, not CPU time) than time.time()? ...or maybe it is my Tween class code that is wrong. It is based on the excellent Robert Penner easing equations. Maybe there is something wrong with my Tween.tick(t) method. Can you guys take a look ? You can download my tweening test here : http://alexandre.quessy.net/static/pygame/tween_progress.tar.gz (this code is part of toonloop.com) -- Alexandre Quessy http://alexandre.quessy.net/
Re: [pygame] Time-based interpolation :: jitter problem
It's a big topic, at best you want to be drawing at the refresh rate of the screen... otherwise you want to aim and get a consistent refresh rate... rather than draw as fast as you can. This is why it can be better to get 20fps consistently rather than 70fps most of the time, and 50fps at other times. It's the non consistent frame rate that can cause jerkyness too. pygame.time.delay will give you more accurate timing on some boxes - at the expense of cpu and power waste. The idea is you find out how much time you need to wait until you next tick will start, and then sleep with that. However it's probably the inconsistent frame rate that is causing the jerkies. cu, On Fri, Jun 19, 2009 at 2:35 PM, Alexandre Quessy wrote: > Hi ! > I am trying to use an interpolation based on time.time() to create > smooth animations with Pygame and OpenGL. > The idea is to get time-based motion tween, instead of frame-based. > It seems like there is still jitter in my interpolation. The motion is > not uniform. > Anyone can propose a more accurate way to measure time > (human-perceived time, not CPU time) than time.time()? > ...or maybe it is my Tween class code that is wrong. It is based on > the excellent Robert Penner easing equations. Maybe there is something > wrong with my Tween.tick(t) method. > Can you guys take a look ? > > You can download my tweening test here : > http://alexandre.quessy.net/static/pygame/tween_progress.tar.gz > (this code is part of toonloop.com) > -- > Alexandre Quessy > http://alexandre.quessy.net/ >
Re: [pygame] Color, unpacking to r,g,b and r,g,b,a - ValueError: too many values to unpack
On Thu, 18 Jun 2009, René Dudfield wrote: This is useful if you want to unpack to r,g,b and not r,g,b,a c = Color(1,2,3,4) c.set_length(3) r,g,b = c what about: r, g, b = c.rgb r, g, b, a = c ? hm i guess nonsensical 'cause not bw compat, and new code could do just: r, g, b, _ = c i don't know, but would vote for something bw compat, 'cause there is quite a lot of old pygame code out there that will probably not be ported and it's always nice to be able to run the old stuff with current libs (instead of trying to have some old pygame installations also besides the current that is used for new dev). ~Toni
Re: [pygame] Color, unpacking to r,g,b and r,g,b,a - ValueError: too many values to unpack
On Fri, Jun 19, 2009 at 2:49 PM, Toni Alatalo wrote: > On Thu, 18 Jun 2009, René Dudfield wrote: > >> This is useful if you want to unpack to r,g,b and not r,g,b,a > > c = Color(1,2,3,4) > c.set_length(3) > r,g,b = c > > what about: > > r, g, b = c.rgb yeah, that's a very cool way to access it. It's what you can do with newer vector languages (eg glsl/cg etc). They call them swizzle operators. Maybe after 1.9.0. As you mention backwards compatibility is quite important... set_length will mainly be for backwards compat... rather than breaking a few games which are packaged in 50 different distros, and then having them not upgrade pygame for ages because it breaks a few games... which is what slowed down uptake for pygame 1.8.1. So this time I'm trying to make sure games/apps included in distros are not broken by the release - at least trying not to break as many as possible. cu,
[pygame] To Marcus, regarding pgreloaded
In honor of the 1-month anniversary of you putting pgreloaded and the associated docs out there, I just browsed the repository and found sdlconstants.rst. Since you asked me to point out issues with the documentation: 1) You've done a great job providing the list of keyboard constants I asked for - thanks, by the way - but lists of attributes associated with other constants are still missing. The example I used last time were the JOYBUTTONUP and JOYBUTTONDOWN event constants having "which," "joy," "button" and "state" attributes; these are still undescribed (and even unmentioned), although at least the constants themselves have descriptions now. 2) The next-to-last part, "keyboard modifer states," is described as a list of constants. If I'm understanding their role correctly, wouldn't these be reserved VARIABLES (specifically, booleans) as their values would change depending on what keys are pressed? That said, looks like good progress so far. Any plans for another formal release, or is that still over the horizon for now?
