Re: [pygame] Playing MP3 problem (background noise)
Well..., I've been looking around and I'm almost convinced that this
isn't an pygame/SDL problem. Since it also happens to .ogg and .wav
files and I have the same problem when using play (sox) to play an wav
file, but not with other players like mplayer. It seems some kind of
ALSA init stuff.
Thanks,
Nelson
Luke Paireepinart wrote:
Nelson wrote:
Hi,
The scenario is an fully updated FC6, with the SDL.mixer recompiled
to enable mp3 support like this:
1) download SDL_mixer-1.2.7-2.fc6.src.rpm from source rpm repository.
2) rpm -i SDL_mixer-1.2.7-2.fc6.src.rpm 3) cd /usr/src/redhat/SPECS
4) edit SDL_mixer.spec, and change line 48 from: %configure
--disable-dependency-tracking --disable-static to %configure
--disable-dependency-tracking --disable-static --enable-music-mp3 5)
build the rpms: rpmbuild -bb SDL_mixer.spec 6) install: cd
/usr/src/redhat/RPMS/i386; rpm -i SDL_mixer-1.2.7-2.i386.rpm; rpm -i
SDL_mixer-devel-1.2.7-2.i386.rpm 7) yum install pygame pygame-devel
The code is:
import pygame
pygame.init()
pygame.mixer.init()
pygame.mixer.music.load('s.mp3')
pygame.mixer.music.play()
while 1:
pass
The s.mp3 is an valid MP3 that mplayer plays without problems, but
the above code plays the mp3 with an annoying background noise (it
looks like an very old vinyl LP disc). Is this an pygame problem or
an SDL problem? Did anyone had the same problem (i tryed on 2
different systems with the same effect (FC6 and CentOS5).
Thanks,
Nelson
Lots of other people had this problem when Feisty Fawn came out. Look
in the archives and see if any of those fixes work for you.
[pygame] Mac OS X 10.5, Leopard Support
Hello. What's the statup of PyGame for Leopard? Compiling with Macports or Fink doesn't work due to the dependancy on PyObjC. PyObjC got re-written for Leopard and is now v2.0. It is included with the OS version of Python (v1.4 simply won't compile under Leopard). The OS Python version ofcourse lacks other stuff that pygame needs like numeric and SDL. One strange detail is that PyObjC's sourceforge page hasn't been updated to reflect the v2.0 re-write. Maybe that's why the fink people can't the pygame build work for leopard. Anyways, if any of you guys got pygame running under leopard, please tell how. If you know anything that might help on the matter, please also tell :) _ Spara, redigera och organisera dina foton enkelt med Photo Gallery! http://get.live.com/photogallery/overview
Re: [pygame] Good code
Hi all, Thanks a bunch for the advice! I will try to follow it (even though I can already tell I am terrible at using functions :) mundial On Dec 9, 2007, at 10:33 AM, David Gowers wrote: Hi Laura On Dec 9, 2007 6:04 PM, Laura Creighton [EMAIL PROTECTED] wrote: I think one of the most useful places to write comments -- and one which I think is rarely done -- is # hack hack hack ! this function should really do XXX instead of YYY # that it does now This is a great use of comments. In open source software, there is a casual convention like: # XXX simplify the logic of this function . In some games, notably *angband, this evolves into # XXX hack: force a 'good' depth. (in distinction from XXX - 'XXX' just meaning code that does not give you a good feeling about how it does things, whereas 'XXX hack' is meaning something that you know is inappropriate to do but currently works.) That way, when you come across it later, you can be sure that this is code you meant to clean up and never got around to, rather than code that was done in this strange way on purpose. Laura
[pygame] split newbie strikes back
Hi all, Following your wise advice, I have used the split screen technique that Casey wrote about, and everything worked great ... until I tried to create sprites that spawned on the bottom screen, to which it politely refuses. All the sprites are instantiated in the top screen, and I have no idea why (I think it's because this subsurface method creates a child of the top_screen, and then when assigning random positions, it all gets messed up). Anyway, if any can help, my code is here: http://tinyurl.com/349wk9 thanks for the help! mundial PS: any feedback on the (messy, ugly) code, is very welcome
Re: [pygame] split newbie strikes back
Mundial 82 wrote: Following your wise advice, I have used the split screen technique that Casey wrote about, and everything worked great ... until I tried to create sprites that spawned on the bottom screen, to which it politely refuses. All the sprites are instantiated in the top screen, and I have no idea why (I think it's because this subsurface method creates a child of the top_screen, and then when assigning random positions, it all gets messed up). playerTop.draw(screen) playerBot.draw(screen) topPoints.draw(screen) botPoints.draw(screen) Try changing to: playerTop.draw(top_screen) playerBot.draw(bot_screen) topPoints.draw(top_screen) botPoints.draw(bot_screen) etc. Also, your check_bounds for the Square class doesn't make sense. The purpose of using subsurfaces is that you don't have to worry about where the sprite.rect is relative to the parent surface, only the child surface. I changed that to this: def checkBounds(self): if self.rect.centerx self.screen.get_width(): self.rect.centerx = 0 if self.rect.centerx 0: self.rect.centerx = self.screen.get_width() if self.rect.centery self.screen.get_height(): self.rect.centery = 0 if self.rect.centery 0: self.rect.centery = self.screen.get_height() I'd be a little wary of blending your sprite-drawing code and your physics code like this, though. Hope this helps! Ethan signature.asc Description: OpenPGP digital signature
Re: [pygame] Hi I'm New
Thank you for bringing that to my attention. I've never had trouble with that so I was unaware of the problem. I was trying to save steps but I certainly don't want to cause confusion. Luke Paireepinart [EMAIL PROTECTED] wrote: Please, don't hit reply and change the subject when creating a new thread. There are other factors than just the subject that e-mail clients use to thread messages, so your post (and all replies) end up under the Playing MP3 Problem thread in my e-mail client, instead of in a separate one. Thanks, -luke Please visit our website www.earlylightpublishing.com - Never miss a thing. Make Yahoo your homepage.
Re: [pygame] Mac OS X 10.5, Leopard Support
I've asked the same thing twice on this list, and gotten zero response. I also asked the macports people for help, zero response. I also asked the PyObjC people for help, and basically got PyObjC 2 is included with Leopard, duh as a response - as if that somehow helps. I've since discovered and migrated half of my projects to pyglet, ( http://pyglet.org ). One binary OS X installer, no dependencies, and it works with the system python (so I don't have to worry about macports, hooray!). YMMV. The PyObjC people said their pages haven't been updated because (basically) they're busy. If you're dead set on using pygame, I do know that you can copy a Tiger macports installation of pygame, and it will work. I didn't go that route, because I wanted to use python 2.5 and I found pyglet to be easier to use anyway. ~ Nathan On Dec 10, 2007 5:11 AM, Olle Olsson [EMAIL PROTECTED] wrote: Hello. What's the statup of PyGame for Leopard? Compiling with Macports or Fink doesn't work due to the dependancy on PyObjC. PyObjC got re-written for Leopard and is now v2.0. It is included with the OS version of Python (v1.4 simply won't compile under Leopard). The OS Python version ofcourse lacks other stuff that pygame needs like numeric and SDL. One strange detail is that PyObjC's sourceforge page hasn't been updated to reflect the v2.0 re-write. Maybe that's why the fink people can't the pygame build work for leopard. Anyways, if any of you guys got pygame running under leopard, please tell how. If you know anything that might help on the matter, please also tell :) _ Spara, redigera och organisera dina foton enkelt med Photo Gallery! http://get.live.com/photogallery/overview
Re: [pygame] split newbie strikes back
Hi, Ethan, that was right on spot! Now I do feel like an idiot! (i was just drawing things in the wrong place, d'oh!) About the physics code - it is the method I learned from Andy Harris' Game Programming book. I think it's a great book (it put me up to speed with pygame in about a month), but I guess it is a beginners book after all. So what should I do, a function that checks the boundaries? (and same goes for all the physics checking?) thanks a bunch once again! mundial On 12/10/07, Ethan Glasser-Camp [EMAIL PROTECTED] wrote: Mundial 82 wrote: Following your wise advice, I have used the split screen technique that Casey wrote about, and everything worked great ... until I tried to create sprites that spawned on the bottom screen, to which it politely refuses. All the sprites are instantiated in the top screen, and I have no idea why (I think it's because this subsurface method creates a child of the top_screen, and then when assigning random positions, it all gets messed up). playerTop.draw(screen) playerBot.draw(screen) topPoints.draw(screen) botPoints.draw(screen) Try changing to: playerTop.draw(top_screen) playerBot.draw(bot_screen) topPoints.draw(top_screen) botPoints.draw(bot_screen) etc. Also, your check_bounds for the Square class doesn't make sense. The purpose of using subsurfaces is that you don't have to worry about where the sprite.rect is relative to the parent surface, only the child surface. I changed that to this: def checkBounds(self): if self.rect.centerx self.screen.get_width(): self.rect.centerx = 0 if self.rect.centerx 0: self.rect.centerx = self.screen.get_width() if self.rect.centery self.screen.get_height(): self.rect.centery = 0 if self.rect.centery 0: self.rect.centery = self.screen.get_height() I'd be a little wary of blending your sprite-drawing code and your physics code like this, though. Hope this helps! Ethan
Re: [pygame] split newbie strikes back
Miguel Sicart wrote: About the physics code - it is the method I learned from Andy Harris' Game Programming book. I think it's a great book (it put me up to speed with pygame in about a month), but I guess it is a beginners book after all. So what should I do, a function that checks the boundaries? (and same goes for all the physics checking?) I personally would prefer to structure things as: Sprite keeps a reference to the object it represents. Sprite.update() changes self.rect.center to be object.pos A separate function or class or something changes the velocity of the object and its position as needed. But note that I don't speak with authority here; it's possible that your structure works better for some types of games. (I was developing using an external physics library, Open Dynamics Engine, so I *had* to keep my physics separate in some way.) Ethan signature.asc Description: OpenPGP digital signature
