Re: [pygame] write sound to file for fast loading?
On Tue, Feb 2, 2010 at 9:27 AM, B W wrote:
> These are .ogg loading from disk using pygame.mixer.Sound('filename.ogg'),
> the largest of which is 7 MB.
>
> I can't believe I overlooked pygame.mixer.music. Pardon me while I flog
> myself.
>
> This does exactly what I want. Thanks, Brian and Olof, for suggesting it!
> Works like a charm.
>
> Gumm
>
Of course the big downside to mixer.music, is that you can only have one
file loaded at once. This is bad if you want to mix :) Then you have to use
sounds, and suffer the loading issues.
Re: [pygame] write sound to file for fast loading?
These are .ogg loading from disk using pygame.mixer.Sound('filename.ogg'),
the largest of which is 7 MB.
I can't believe I overlooked pygame.mixer.music. Pardon me while I flog
myself.
This does exactly what I want. Thanks, Brian and Olof, for suggesting it!
Works like a charm.
Gumm
Re: [pygame] BUG: The behavior of the Group.has method vs. its documentation
Ah yeah thats sounds better, didn't thought about it that way. I would agree with your options, making Group.has as stated in the documentation and Group.hasany so it looks if at least one sprite is in the group. So your example grp1.has(grp2) would return False where grp1.hasany(grp2) would return True. Though i don't know if group.hasany would be needed by anyone (only thought about it because thats what group.has is currently doing... more or less). Greetz, Yannick btw. "mfg" is german equivalent of "yours sincerely" (or something around that) and not my name ^^ didn't want to confuse anybody here ^^ Original-Nachricht > Datum: Tue, 2 Feb 2010 04:43:04 -0800 (PST) > Von: "Jason M. Marshall" > An: pygame-users@seul.org > Betreff: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > mfg, > > I would be OK with that. A second option would be to keep Group.has as the > checker for membership of ALL sprites passed as arguments (and make its > implementation and documentation match perfectly) and make a new Group.hasany > method to check for membership of ANY sprites passed as arguments.. The > advantage of this second option would be that it wouldn't break existing code > that passes one Group as an argument to another Group's has method.. For > example: > > >>> from pygame.sprite import Group, Sprite > >>> spr1 = Sprite() > >>> spr2 = Sprite() > >>> grp1 = Group(spr1) > >>> grp2 = Group(spr1, spr2) > >>> grp1.has(grp2) # The suggestion by mfg would make this return True > False > >>> grp2.has(grp1) > True > > René, I think that we need a decisive pronouncement from the BDSP1.7 > (Benevolent Dictator Since Pygame 1.7). It'll affect how I update the > pygame.sprite unittest. > > Thanks, > Jason > > > - Original Message > From: Yannick Weinz > To: pygame-users@seul.org > Sent: Tue, February 2, 2010 5:11:43 AM > Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > > Hi, > > I would suggest changing the code so that Group.has tests, if any of the > given sprites is inside the Group (Group.has(spr1,spr2) returns True if > spr1, spr2 or spr1 and spr2 are in the group, otherweise False) and adding > another function Group.hasall that tests if all of the given sprites are > inside > the Group (group.has(spr1,spr2) returns True if spr1 and spr2 are in the > Group, otherwise False). Then Group.hasall would behave according to the > documentation of Group.has. > > mfg > > > Original-Nachricht > > Datum: Mon, 1 Feb 2010 05:10:41 -0800 (PST) > > Von: "Jason M. Marshall" > > An: pygame-users@seul.org > > Betreff: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > > > PS. Actually, I just realized that Group.has only checks the membership > of > > the first sprite when I call grp1.has(spr1, spr2). It's not checking the > > membership of any of the arguments after the first one. This makes me > even > > more certain that it would be preferable to change the code. > > > > > > - Original Message > > From: Jason M. Marshall > > To: pygame-users@seul.org > > Sent: Mon, February 1, 2010 6:28:59 AM > > Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its > > documentation > > > > Unfortunately, correcting the documentation will make it complicated. If > > we correct the documentation, then we'll have to explain why Group.has > > checks for membership of ANY sprites that are passed as arbitrary > arguments but > > checks for membership of ALL sprites that are passed as objects within > an > > iterable. > > > > >>> grp1.has(spr1, spr2) > > True > > >>> grp1.has([spr1, spr2]) > > False > > > > Since the actual implementation is nuanced, would it still be best to > > update the documentation rather than change the code? (We could consider > the > > nuance a feature!) > > > > unittests are a good idea. I'll add those. > > > > Jason > > > > - Original Message > > From: René Dudfield > > To: pygame-users@seul.org > > Sent: Mon, February 1, 2010 5:42:38 AM > > Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its > > documentation > > > > On Mon, Feb 1, 2010 at 7:15 PM, Jason M. Marshall > wrote: > > > In the pygame.sprite module, I think that the Group.has method does > not > > behave according to its documentation. The online documentation states > that > > Group.has will return True if the Group contains ALL of the given > sprites. > > However, in a certain case, Group.has will return True if the Group > > contains ANY of the given sprites. In the following interactive code > example, > > grp1.has(spr1, spr2) should return False, but it returns True: > > > > > import pygame > > spr1 = pygame.sprite.Sprite() > > spr2 = pygame.sprite.Sprite() > > grp1 = pygame.sprite.Group(spr1) > > grp1.has(spr1) > > > True > > grp1.has(spr2) > > > False > > grp1.has(spr2, spr1) > >
Re: [pygame] Pygame2 SDL_mixer segmentation fault
On Mon, Feb 1, 2010 at 4:50 AM, Marcus von Appen wrote: > It looks, like opening the audio device requires thread support on some > platforms. I changed the sdlmixer.open_audio() call to support threads, > which seems to fix the problem. > While working on that, sdlmixer.init() was changed to support the > optional INIT_FLAC/INIT_MOD... arguments properly, so do not forget to > initialize sdlmixer with something like: > >import pygame2.sdlmixer as sdlmixer > import pygame2.sdlmixer.constants as const >... >sdlmixer.init (const.INIT_FLAC|const.INIT_MOD...) >... > > if you want support for additional audio formats. > > The changes are committed in SVN revision 2740. > > Regards > Marcus > Thanks for figuring this out; SDL mixer works perfectly now. -- Evan Kroske http://welcome2obscurity.blogspot.com/ The personal blog of Evan Kroske, novice software developer.
Re: [pygame] BUG: The behavior of the Group.has method vs. its documentation
mfg, I would be OK with that. A second option would be to keep Group.has as the checker for membership of ALL sprites passed as arguments (and make its implementation and documentation match perfectly) and make a new Group.hasany method to check for membership of ANY sprites passed as arguments.. The advantage of this second option would be that it wouldn't break existing code that passes one Group as an argument to another Group's has method.. For example: >>> from pygame.sprite import Group, Sprite >>> spr1 = Sprite() >>> spr2 = Sprite() >>> grp1 = Group(spr1) >>> grp2 = Group(spr1, spr2) >>> grp1.has(grp2) # The suggestion by mfg would make this return True False >>> grp2.has(grp1) True René, I think that we need a decisive pronouncement from the BDSP1.7 (Benevolent Dictator Since Pygame 1.7). It'll affect how I update the pygame.sprite unittest. Thanks, Jason - Original Message From: Yannick Weinz To: pygame-users@seul.org Sent: Tue, February 2, 2010 5:11:43 AM Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its documentation Hi, I would suggest changing the code so that Group.has tests, if any of the given sprites is inside the Group (Group.has(spr1,spr2) returns True if spr1, spr2 or spr1 and spr2 are in the group, otherweise False) and adding another function Group.hasall that tests if all of the given sprites are inside the Group (group.has(spr1,spr2) returns True if spr1 and spr2 are in the Group, otherwise False). Then Group.hasall would behave according to the documentation of Group.has. mfg Original-Nachricht > Datum: Mon, 1 Feb 2010 05:10:41 -0800 (PST) > Von: "Jason M. Marshall" > An: pygame-users@seul.org > Betreff: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > PS. Actually, I just realized that Group.has only checks the membership of > the first sprite when I call grp1.has(spr1, spr2). It's not checking the > membership of any of the arguments after the first one. This makes me even > more certain that it would be preferable to change the code. > > > - Original Message > From: Jason M. Marshall > To: pygame-users@seul.org > Sent: Mon, February 1, 2010 6:28:59 AM > Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > > Unfortunately, correcting the documentation will make it complicated. If > we correct the documentation, then we'll have to explain why Group.has > checks for membership of ANY sprites that are passed as arbitrary arguments > but > checks for membership of ALL sprites that are passed as objects within an > iterable. > > >>> grp1.has(spr1, spr2) > True > >>> grp1.has([spr1, spr2]) > False > > Since the actual implementation is nuanced, would it still be best to > update the documentation rather than change the code? (We could consider the > nuance a feature!) > > unittests are a good idea. I'll add those. > > Jason > > - Original Message > From: René Dudfield > To: pygame-users@seul.org > Sent: Mon, February 1, 2010 5:42:38 AM > Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > > On Mon, Feb 1, 2010 at 7:15 PM, Jason M. Marshall wrote: > > In the pygame.sprite module, I think that the Group.has method does not > behave according to its documentation. The online documentation states that > Group.has will return True if the Group contains ALL of the given sprites. > However, in a certain case, Group.has will return True if the Group > contains ANY of the given sprites. In the following interactive code example, > grp1.has(spr1, spr2) should return False, but it returns True: > > > import pygame > spr1 = pygame.sprite.Sprite() > spr2 = pygame.sprite.Sprite() > grp1 = pygame.sprite.Group(spr1) > grp1.has(spr1) > > True > grp1.has(spr2) > > False > grp1.has(spr2, spr1) > > False > grp1.has(spr1, spr2) > > True > > > > > I'm already in the process of tidying up the pygame.sprite module so > that it'll make fewer function calls, make fewer hash table look-ups and > conform to PEP 8 better. So far, I haven't made any changes that could break > any > existing code, but if I change the AbstractGroup.has code to match the > documentation, then someone's game could break if it depends on the incorrect > behavior of Group.has. > > > > Would it be OK with all of you if I change Group.has to match the > documentation? > > > > Thanks, > > Jason > > > > > Best to fix the docs, and add another method. > > Also, there are not full unittests for the sprite module, so it would > be good to get some unittests completed first... so that it would be > sure to catch any errors with your refactoring. > > > cu, > > > -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Re: [pygame] BUG: The behavior of the Group.has method vs. its documentation
Hi, I would suggest changing the code so that Group.has tests, if any of the given sprites is inside the Group (Group.has(spr1,spr2) returns True if spr1, spr2 or spr1 and spr2 are in the group, otherweise False) and adding another function Group.hasall that tests if all of the given sprites are inside the Group (group.has(spr1,spr2) returns True if spr1 and spr2 are in the Group, otherwise False). Then Group.hasall would behave according to the documentation of Group.has. mfg Original-Nachricht > Datum: Mon, 1 Feb 2010 05:10:41 -0800 (PST) > Von: "Jason M. Marshall" > An: pygame-users@seul.org > Betreff: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > PS. Actually, I just realized that Group.has only checks the membership of > the first sprite when I call grp1.has(spr1, spr2). It's not checking the > membership of any of the arguments after the first one. This makes me even > more certain that it would be preferable to change the code. > > > - Original Message > From: Jason M. Marshall > To: pygame-users@seul.org > Sent: Mon, February 1, 2010 6:28:59 AM > Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > > Unfortunately, correcting the documentation will make it complicated. If > we correct the documentation, then we'll have to explain why Group.has > checks for membership of ANY sprites that are passed as arbitrary arguments > but > checks for membership of ALL sprites that are passed as objects within an > iterable. > > >>> grp1.has(spr1, spr2) > True > >>> grp1.has([spr1, spr2]) > False > > Since the actual implementation is nuanced, would it still be best to > update the documentation rather than change the code? (We could consider the > nuance a feature!) > > unittests are a good idea. I'll add those. > > Jason > > - Original Message > From: René Dudfield > To: pygame-users@seul.org > Sent: Mon, February 1, 2010 5:42:38 AM > Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its > documentation > > On Mon, Feb 1, 2010 at 7:15 PM, Jason M. Marshall wrote: > > In the pygame.sprite module, I think that the Group.has method does not > behave according to its documentation. The online documentation states that > Group.has will return True if the Group contains ALL of the given sprites. > However, in a certain case, Group.has will return True if the Group > contains ANY of the given sprites. In the following interactive code example, > grp1.has(spr1, spr2) should return False, but it returns True: > > > import pygame > spr1 = pygame.sprite.Sprite() > spr2 = pygame.sprite.Sprite() > grp1 = pygame.sprite.Group(spr1) > grp1.has(spr1) > > True > grp1.has(spr2) > > False > grp1.has(spr2, spr1) > > False > grp1.has(spr1, spr2) > > True > > > > > I'm already in the process of tidying up the pygame.sprite module so > that it'll make fewer function calls, make fewer hash table look-ups and > conform to PEP 8 better. So far, I haven't made any changes that could break > any > existing code, but if I change the AbstractGroup.has code to match the > documentation, then someone's game could break if it depends on the incorrect > behavior of Group.has. > > > > Would it be OK with all of you if I change Group.has to match the > documentation? > > > > Thanks, > > Jason > > > > > Best to fix the docs, and add another method. > > Also, there are not full unittests for the sprite module, so it would > be good to get some unittests completed first... so that it would be > sure to catch any errors with your refactoring. > > > cu, > > > -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Re: [pygame] write sound to file for fast loading?
2010/2/2 机械唯物主义 :
> emmm...
>
> large music file ---> longger loading time..
> the file is not buffered?
>
> can you post a sample code ?
Well I just asumed music was being streamed from disc in pygame.music:
import pygame
pygame.init()
pygame.music.load('some_file.ogg')
pygame.music.play()
I have never used pygame.music with .ogg files larger than 5 mb, so I
cannot say whether my assumption is valid or not.
What file format are you using?
>
> On Tue, Feb 2, 2010 at 3:24 PM, Olof Bjarnason
> wrote:
>> 2010/2/2 B W :
>>> Howdy, folks.
>>>
>>> I have a problem I've been studying a while and I can't figure out a
>>> solution. Pygame or SDL--not sure which--is pretty slow at loading sounds.
>>> For large sounds, like songs, this means significant pauses in your game; or
>>> very long loading times at startup if you have a few of them to load.
>>
>> Tried pygame music?
>>
>> http://www.pygame.org/docs/ref/music.html
>>
>>>
>>> I tried using a thread to load a song, but as expected that only resulted in
>>> a very laggy game for the duration.
>>>
>>> So I was thinking it might be faster to pre-process a song: load it via the
>>> mixer, write the buffer to a data file, then later load it into an array and
>>> feed the array to the mixer. I can see that part of that idea is implemented
>>> in _sndarray.py, but I didn't really want to require numpy and I couldn't
>>> see how to convert that module's code to my purpose anyhow.
>>>
>>> I'm strikin' out. Is this even feasible, or is it a hair-brained scheme
>>> doomed to failure? Has anyone solved this problem, and would s/he be willing
>>> to share? :)
>>>
>>> Gumm
>>>
>>
>>
>>
>> --
>> http://olofb.wordpress.com
>>
>
--
http://olofb.wordpress.com
