[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] vista testing...
Hi Doug,
Of course, I forgot! How stupid, just one of those UNIX things that when
never using that stuff any more, you forget. I should have known, but when
half asleep when writing it and testing it, it is easy to forget. It had
been months since I had an issue of using control chars and such. Makes
complete sense now.
Now I have to clean up my game and get the help menu score card stuff up
in a F key and fix the computer look-ahead turn and such.
It works fine as is for playing with just the toggle back and forth.
Bruce
Bruce,
It looks like you are mixing Windows paths (backslash) with Python
strings. "\awe" means something different from "\\awe". Python strings
are pretty smart in figuring out what you mean, but can't do it in all
cases. \a means, I think, "ring the bell"; \n is newline, etc.
I think if you use a single forward slash, or double backslash you'll be ok.
-Doug
FT wrote:
> Hi Lenard
>
> your not going to believe this after extensive testing, what was
needed
> was the import os.path for that file and only that file would not play
> without the path.
>
> I am not joking about this, for I tested all the files inside the data
> folder from the folder above and all would work but the Awes file. But
when
> placing that file in the same directory as the .py file it worked. So I
> decided to insert the os.path.join() into the file name for the mixer and
it
> worked. It runs now without any problem.
>
> So, the question to ask is why only that file? No other file inside
the
> data folder had an error and I have all sizes and shapes being run in my
> battleship program. All them on the list have the "data\name" filename
> inside the .mixer assignment. But only the awes file would say mixer load
> error of no src, for it could not find the file.
>
> Talk about weird situations. So your test below failed until I added
the
> os.path command. I inserted it into my battle.py game and it works now.
> Later I will do the assignments inside a method.
>
> The game is attached with the awe file inside the boohoo name. I guess
> you could use your own files for sound unless I send it zipped up.
>
> Bruce
>
> Without calling pygame.mixer.pre_init the mixer defaults to a 22050
> sample rate and a 3072 byte buffer. The following test program played
> the attached wave file with problem.
>
>
> import pygame
>
> pygame.init()
>
> sound = pygame.mixer.Sound("Awes.wav")
> sound.play()
>
> while pygame.mixer.get_busy():
> pass
>
>
> Lenard
>
>
> FT wrote:
>> Hi!
>> I am not sure if this is related because I do not get any scratching
> on
>> my sounds when I only use pygame.init with no mixer init but the attached
>> file, the only one of the bunch I have will not play at all. In fact it
> says
>> error, no src. Also it says it is a null file.
>> It is an 8 bit, 88K but I have many like this one but they play with
> no
>> problems or scratching. I use both 8 bit and 16 bit and one is played
>> continuously, but this one dies once assigned with the null, no src
error.
>>
>> So, what is the difference in this file from all others when trying
to
>> play it with the mixer? You have to convert it back to a .wav file for
the
>> list rejected with the extension on it, so I sent it without it.
>>
>> I am using pygame 1.8 rc 3 and SDL (1,2,12)
>>
>> Bruce
>>
>>
>> When you say "that didn't work at all", what exactly do you mean? What
>> SDL prebuilts were you running with what pygame when you had a
>> problem?
>>
>> In terms of not working - do you mean you get a python exception? seg
>> fault? stuff seemed to work but no sound played?
>>
>> Also, while I haven't tried an older SDL with pygame 1.8. I've
>> successfully used the newer SDL dll's with pygame 1.7.
>>
>> So if the problems you had were trying to run the SDL from 1.7 with
>> pygame 1.8, then maybe you can try pygame 1.7.1 with the newer SDL
>> dll's here:
>> http://www3.telus.net/len_l/prebuilt-msvcr71.zip
>> the result of that one test case will provide useful info on if this
>> is an SDL bug or not.
>>
>>
>> On Mon, Mar 24, 2008 at 4:05 PM, Bo Jangeborg <bo@xxxxxxxxxxx> wrote:
>>
>>> Did try that yesterday but that didn't work at all.
>>> I don't think the different versions of the mixer are
>>> compatible.
>>>
>>> Brian Fisher skrev:
>>>
>>>
>>>
>>>> One other thing to try would be to swap out different SDL library
>>>>
>>> > versions. Pygame 1.8 includes newer SDL library versions than 1.7
>>> > does, I think SDL mixer was updated as part of that.
>>> >
>>> > You should be able switch being using the dll's for 1.7 here:
>>> > http://pygame.org/ftp/win32-dependencies.zip
>>> >
>>> > and the dll's for 1.8 here:
>>> > http://www3.telus.net/len_l/prebuilt-msvcr71.zip
>>> >
>>> > just by copying the dll's over the ones in your site-packages/pygame
>>>
>> dir.
>>
>>> >
>>> > so if you get scratchiness in both pygame 1.7 & 1.8 with the newer
SDL
>>> > but not with the older SDL, it would seem to be a new SDL bug. if you
>
>>> > get scratchiness in pygame 1.8 with either SDL, but not in pygame 1.7
>>> > with either SDL, then it would seem to be something pygame
introduced.
>>> >
>>> >
>>> > On Mon, Mar 24, 2008 at 2:20 PM, Bo Jangeborg <bo@xxxxxxxxxxx> wrote:
>>> >
>>> >> Just tried it, no differens I am afraid. One thing I noticed , and
>>>
>> that
>>
>>> >> was true for
>>> >> the mingw version too, was that at 44k the music was running
>>> >> considerally slower.
>>> >> Not sure if that's any clue.
>>> >> Is the interrrupt not frequent enough for it to pump out the music
?
>>>
>> Or
>>
>>> >> what do
>>> >> think is happening here. Do you have any compiler options to play
>>>
>> around
>>
>>> >> with ?
>>> >>
>>> >> René Dudfield skrev:
>>> >>
>>> >>
>>> >>
>>> >>> Are you able to try the pygame from here ?
>>> >>>
>>> >> > http://thorbrian.com/pygame/builds.php
>>> >> >
>>> >> > I think this is compiled with visual C rather than mingw, so
maybe
>>> >> > it'll be different...
>>> >> >
>>> >> > cheers,
>>> >> >
>>> >> > On Mon, Mar 24, 2008 at 11:21 PM, Bo Jangeborg <bo@xxxxxxxxxxx>
>>>
>> wrote:
>>
>>> >> >
>>> >> >> The scratching are with all music files I have tested. The music
>>>
>> have a
>>
>>> >> >> native sample rate
>>> >> >> of 44k so there should be no need to resample, and it does work
>>>
>> when the
>>
>>> >> >> output is changed
>>> >> >> to 22k. I have tested with 15 different pieces. Furthermore it
>>>
>> worked ok
>>
>>> >> >> in pygame 1.7.
>>> >> >>
>>> >> >> If I start a bit into the music I get occasional scratching for
>>>
>> the rest
>>
>>> >> >> of the piece after that.
>>> >> >>
>>> >> >> Brian Fisher skrev:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>> The change with sample rate makes me think it may actually have
>>>
>> to do
>>
>>> >> >>>
>>> >> >> > with the particular sound samples as well? I understand that
>>>
>> SDL is
>>
>>> >> >> > somewhat limited on the sample rate conversions it supports -
>>>
>> got
>>
>>> >> >> > particular sounds files that sound scratchy you can send to
>>>
>> test with?
>>
>>> >> >> >
>>> >> >> > also, when you say you get scratches after starting some way
>>>
>> into the
>>
>>> >> >> > music - do you mean you get like a pop when first playing the
>>>
>> music,
>>
>>> >> >> > or do you mean that you get scratches throughout the music
>>>
>> after you
>>
>>> >> >> > start it playing at a point in the sound?
>>> >> >> >
>>> >> >> >
>>> >> >> > On Sun, Mar 23, 2008 at 2:27 PM, Bo Jangeborg
<bo@xxxxxxxxxxx>
>>>
>> wrote:
>>
>>> >> >> >
>>> >> >> >> The buffer setting doesn't seem to make a differens.
>>> >> >> >> The key seem to be the sampling rate. Lots of scratching at
>>>
>> 44k sound
>>
>>> >> >> >> but OK at 22k. But even then I get scratches if I start
some
>>>
>> way into
>>
>>> >> >> >> the music
>>> >> >> >> rather then at the start. The later problem I had in pygame
>>>
>> 1.7 too.
>>
>>> >> >> >>
>>> >> >> >> In pygame 1.7 music worked OK in Vista at 44k.
>>> >> >> >> I have tried both ogg and mp3 in pygame 1.8.
>>> >> >> >> Have you tried playing music at 44k on XP machines? Maybe
>>>
>> this is a more
>>
>>> >> >> >> general problem.
>>> >> >> >>
>>> >> >> >> Another thing that seem to have changed is that if a path
to
>>>
>> a sound file
>>
>>> >> >> >> is wrong it doesn't cause an exception. Instead it returns
> an
>> empty
>>
>>> >> >> >> sound object..
>>> >> >> >> Is that really intended ?
>>> >> >> >>
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG.
>> Version: 7.5.519 / Virus Database: 269.21.8/1340 - Release Date:
3/23/2008
>
>> 6:50 PM
>>
>
>
> --
> Lenard Lindstrom
> <len-l@xxxxxxxxx>
>
--
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.0/1342 - Release Date: 3/25/2008
10:26 AM