[pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
Hello Pygame developers: Please read entire message before assuming you've heard this before:) I am a new user of Pygame. I have the book Beginning Game Dev with Python and Pygame. So far I am very impressed with Pygame; It has excellent graphics response and input capabilities. The sound Mixer library has problems though. When I tried the examples in Chapter 10 Making Things Go Boom, I noticed a Crackling noise when playing sound effects (short wav files) and music (long Ogg files). I have searched the archives at Seul.org and searched on Google for fixes to this problem. The solutions suggested basically amount to changing arguments passed into: pygame.mixer.pre_init(...) I tried many different settings: pygame.mixer.pre_init(44100, -16, 2, 4096) pygame.mixer.pre_init(22050, -16, 2, 4096) pygame.mixer.pre_init(22050, 16, 2, 1024 * some_number) Too many to keep listing. I also tried leaving the settings at default, which actually produces the least amount to crackling. I played the music/sound files with Windows Media Player to rule out my system or bad files. There was no crackling there. On some of the Google searches, I saw that people were pointing to the problem being in the actual SDL_Mixer. So I downloaded SDL/SDL_Mixer extension and re-wrote the example scripts in SDL/C++, using the same music/sound files. To my surprise, there was NO Crackling noise. So, the problem is NOT my system, it's not the arguments I'm passing into pygame.mixer, and it's not SDL_Mixer. The problem has to be somewhere in the Pygame Sound/Music libraries. I even tried swapping out the SDL_Mixer libs that came with Pygame for the ones that came with SDL_Mixer, and still got the crackling in Pygame. It would be nice if this could be fixed. Because the crackling is essentially making the library unuseable. Which would be a shame, because Pygame is a terrific library/tool. Thanks, Ethan D. Systems Programmer, SR. Planetary Lab, Univ Arizona My System: Windows Vista 32bit home premium IP35-Pro mobo, integrated sound, latest drivers 4 Gig RAM Intel Quad core
Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
hi, did your rewritten scripts use video? Or just sound? Do you have a url for your scripts somewhere? cheers, On Fri, Apr 18, 2008 at 4:03 PM, etrek [EMAIL PROTECTED] wrote: Hello Pygame developers: Please read entire message before assuming you've heard this before:) I am a new user of Pygame. I have the book Beginning Game Dev with Python and Pygame. So far I am very impressed with Pygame; It has excellent graphics response and input capabilities. The sound Mixer library has problems though. When I tried the examples in Chapter 10 Making Things Go Boom, I noticed a Crackling noise when playing sound effects (short wav files) and music (long Ogg files). I have searched the archives at Seul.org and searched on Google for fixes to this problem. The solutions suggested basically amount to changing arguments passed into: pygame.mixer.pre_init(...) I tried many different settings: pygame.mixer.pre_init(44100, -16, 2, 4096) pygame.mixer.pre_init(22050, -16, 2, 4096) pygame.mixer.pre_init(22050, 16, 2, 1024 * some_number) Too many to keep listing. I also tried leaving the settings at default, which actually produces the least amount to crackling. I played the music/sound files with Windows Media Player to rule out my system or bad files. There was no crackling there. On some of the Google searches, I saw that people were pointing to the problem being in the actual SDL_Mixer. So I downloaded SDL/SDL_Mixer extension and re-wrote the example scripts in SDL/C++, using the same music/sound files. To my surprise, there was NO Crackling noise. So, the problem is NOT my system, it's not the arguments I'm passing into pygame.mixer, and it's not SDL_Mixer. The problem has to be somewhere in the Pygame Sound/Music libraries. I even tried swapping out the SDL_Mixer libs that came with Pygame for the ones that came with SDL_Mixer, and still got the crackling in Pygame. It would be nice if this could be fixed. Because the crackling is essentially making the library unuseable. Which would be a shame, because Pygame is a terrific library/tool. Thanks, Ethan D. Systems Programmer, SR. Planetary Lab, Univ Arizona My System: Windows Vista 32bit home premium IP35-Pro mobo, integrated sound, latest drivers 4 Gig RAM Intel Quad core
Re: [pygame] Unexpect blit behavior when using BLEND_ADD
On, Fri Apr 18, 2008, Lenard Lindstrom wrote: Greg Ewing wrote: Lenard Lindstrom wrote: This means inlined blending code will have to be replaced with indirect function calls. Otherwise, with all the possible permutations of blending, alphablit.c will balloon in size uncontrollably. You could make two passes over the surface, one to update the RGB and one to update the alpha. Or you could have a set of blending operations that update the alpha only, and let the user make two blit calls. Having a separate blit_alpha might be the way to go. This may actually remove intermediary steps involving an alpha-only surface. Also, it can be Horrible. Now each blit loop will take about twice the time, because I can't have alpha and RGB modifications at once :-). Regards Marcus pgpMp9q9Ah6r1.pgp Description: PGP signature
Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
Hi,
I didn't use any graphics in my SDL program. Just the SDL_Mixer. Here is
a short example of SDL program that plays the files without noise/crackles.
This was compiled with DEV-C++ and MinGW.
#include stdlib.h
#include SDL.h
#include SDL_Mixer.h
Mix_Chunk* bounce = NULL; // bounce.wav from Book chapter 10
Mix_Chunk* msg = NULL; // Please put some .ogg files in the folder.ogg Book
chapter 10
Mix_Music *music = NULL; // getout.ogg example from the IrrKlang music
library
SDL_Surface* createScreen()
{ SDL_Surface *screen;
screen = SDL_SetVideoMode(640, 480, 16, SDL_SWSURFACE);
if ( screen == NULL ) {
fprintf(stderr, Unable to set 640x480 video: %s\n,
SDL_GetError());
exit(1);
}
return screen;
}
void quit() {
Mix_FreeChunk(bounce) ;
Mix_FreeChunk(msg);
Mix_FreeMusic(music);
Mix_CloseAudio();
SDL_Quit();
}
int main(int argc, char *argv[])
{
if ( SDL_Init(SDL_INIT_EVERYTHING) 0 ) {
fprintf(stderr, Unable to init SDL: %s\n, SDL_GetError());
exit(1);
}
SDL_Surface* screen = createScreen();
SDL_WM_SetCaption( Hello World, NULL );
//Update the screen
if( SDL_Flip( screen ) == -1 ) { return 1; }
// initialize SDL mixer
if( Mix_OpenAudio( 22050, MIX_DEFAULT_FORMAT, 2, 4096 ) == -1 ) //tried
these values in Pygame
{
return false;
}
Mix_AllocateChannels(8);
bounce = Mix_LoadWAV( bounce.wav );
msg = Mix_LoadWAV(please.ogg);
music = Mix_LoadMUS( getout.ogg );
//If there was a problem loading the sound effects
if( bounce == NULL ) { return false; }
SDL_Event event;
while(true) {
while(SDL_PollEvent(event)) {
if(event.type == SDL_QUIT) {
quit();
}
if(event.type == SDL_KEYDOWN) {
if(event.key.keysym.sym == SDLK_1) {
if(Mix_PlayChannel(-1, bounce, 0) 0) {
quit();
}
}
else if(event.key.keysym.sym == SDLK_2) {
if(Mix_PlayChannel(-1, msg, 0) 0) {
quit();
}
}
else if(event.key.keysym.sym == SDLK_3) {
if( Mix_PlayMusic( music, -1 ) 0 ) {
quit();
}
}
}
}
}
return 0;
}
- Original Message -
From: René Dudfield [EMAIL PROTECTED]
To: pygame-users@seul.org
Sent: Thursday, April 17, 2008 11:15 PM
Subject: Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
hi,
did your rewritten scripts use video? Or just sound?
Do you have a url for your scripts somewhere?
cheers,
On Fri, Apr 18, 2008 at 4:03 PM, etrek [EMAIL PROTECTED] wrote:
Hello Pygame developers: Please read entire message before assuming
you've
heard this before:)
I am a new user of Pygame. I have the book Beginning Game Dev with
Python
and Pygame. So far I am very impressed with Pygame; It has excellent
graphics response and input capabilities. The sound Mixer library has
problems though.
When I tried the examples in Chapter 10 Making Things Go Boom, I
noticed
a Crackling noise when playing sound effects (short wav files) and
music
(long Ogg files).
I have searched the archives at Seul.org and searched on Google for
fixes
to this problem. The solutions suggested basically amount to changing
arguments passed into: pygame.mixer.pre_init(...)
I tried many different settings:
pygame.mixer.pre_init(44100, -16, 2, 4096)
pygame.mixer.pre_init(22050, -16, 2, 4096)
pygame.mixer.pre_init(22050, 16, 2, 1024 * some_number)
Too many to keep listing.
I also tried leaving the settings at default, which actually produces the
least amount to crackling.
I played the music/sound files with Windows Media Player to rule out my
system or bad files. There was no crackling there.
On some of the Google searches, I saw that people were pointing to the
problem being in the actual SDL_Mixer.
So I downloaded SDL/SDL_Mixer extension and re-wrote the example scripts
in
SDL/C++, using the same music/sound files.
To my surprise, there was NO Crackling noise.
So, the problem is NOT my system, it's not the arguments I'm passing
into
pygame.mixer, and it's not SDL_Mixer.
The problem has to be somewhere in the Pygame Sound/Music libraries.
I even tried swapping out the SDL_Mixer libs that came with Pygame for
the
ones that came with SDL_Mixer, and still got the crackling in Pygame.
It would be nice if this could be fixed. Because the crackling is
essentially making the library unuseable. Which would be a shame,
because
Pygame is a terrific library/tool.
Thanks,
Ethan D.
Systems Programmer, SR.
Planetary Lab, Univ Arizona
My System:
Windows Vista 32bit home premium
IP35-Pro mobo, integrated sound, latest drivers
4 Gig RAM
Intel Quad core
Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
hi,
I think from our testing that it's the combination of using video with
the sound.
Are you able to play any of the SDL test programs with video and sound
to see if there is crackling?
cheers,
On Fri, Apr 18, 2008 at 5:20 PM, etrek [EMAIL PROTECTED] wrote:
Hi,
I didn't use any graphics in my SDL program. Just the SDL_Mixer. Here is
a short example of SDL program that plays the files without noise/crackles.
This was compiled with DEV-C++ and MinGW.
#include stdlib.h
#include SDL.h
#include SDL_Mixer.h
Mix_Chunk* bounce = NULL; // bounce.wav from Book chapter 10
Mix_Chunk* msg = NULL; // Please put some .ogg files in the folder.ogg Book
chapter 10
Mix_Music *music = NULL; // getout.ogg example from the IrrKlang music
library
SDL_Surface* createScreen()
{ SDL_Surface *screen;
screen = SDL_SetVideoMode(640, 480, 16, SDL_SWSURFACE);
if ( screen == NULL ) {
fprintf(stderr, Unable to set 640x480 video: %s\n, SDL_GetError());
exit(1);
}
return screen;
}
void quit() {
Mix_FreeChunk(bounce) ;
Mix_FreeChunk(msg);
Mix_FreeMusic(music);
Mix_CloseAudio();
SDL_Quit();
}
int main(int argc, char *argv[])
{
if ( SDL_Init(SDL_INIT_EVERYTHING) 0 ) {
fprintf(stderr, Unable to init SDL: %s\n, SDL_GetError());
exit(1);
}
SDL_Surface* screen = createScreen();
SDL_WM_SetCaption( Hello World, NULL );
//Update the screen
if( SDL_Flip( screen ) == -1 ) { return 1; }
// initialize SDL mixer
if( Mix_OpenAudio( 22050, MIX_DEFAULT_FORMAT, 2, 4096 ) == -1 ) //tried
these values in Pygame
{
return false;
}
Mix_AllocateChannels(8);
bounce = Mix_LoadWAV( bounce.wav );
msg = Mix_LoadWAV(please.ogg);
music = Mix_LoadMUS( getout.ogg );
//If there was a problem loading the sound effects
if( bounce == NULL ) { return false; }
SDL_Event event;
while(true) {
while(SDL_PollEvent(event)) {
if(event.type == SDL_QUIT) {
quit();
}
if(event.type == SDL_KEYDOWN) {
if(event.key.keysym.sym == SDLK_1) {
if(Mix_PlayChannel(-1, bounce, 0) 0) {
quit();
}
}
else if(event.key.keysym.sym == SDLK_2) {
if(Mix_PlayChannel(-1, msg, 0) 0) {
quit();
}
}
else if(event.key.keysym.sym == SDLK_3) {
if( Mix_PlayMusic( music, -1 ) 0 ) {
quit();
}
}
}
}
}
return 0;
}
- Original Message - From: René Dudfield [EMAIL PROTECTED]
To: pygame-users@seul.org
Sent: Thursday, April 17, 2008 11:15 PM
Subject: Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
hi,
did your rewritten scripts use video? Or just sound?
Do you have a url for your scripts somewhere?
cheers,
On Fri, Apr 18, 2008 at 4:03 PM, etrek [EMAIL PROTECTED] wrote:
Hello Pygame developers: Please read entire message before assuming
you've
heard this before:)
I am a new user of Pygame. I have the book Beginning Game Dev with
Python
and Pygame. So far I am very impressed with Pygame; It has excellent
graphics response and input capabilities. The sound Mixer library has
problems though.
When I tried the examples in Chapter 10 Making Things Go Boom, I
noticed
a Crackling noise when playing sound effects (short wav files) and
music
(long Ogg files).
I have searched the archives at Seul.org and searched on Google for
fixes
to this problem. The solutions suggested basically amount to changing
arguments passed into: pygame.mixer.pre_init(...)
I tried many different settings:
pygame.mixer.pre_init(44100, -16, 2, 4096)
pygame.mixer.pre_init(22050, -16, 2, 4096)
pygame.mixer.pre_init(22050, 16, 2, 1024 * some_number)
Too many to keep listing.
I also tried leaving the settings at default, which actually produces
the
least amount to crackling.
I played the music/sound files with Windows Media Player to rule out my
system or bad files. There was no crackling there.
On some of the Google searches, I saw that people were pointing to the
problem being in the actual SDL_Mixer.
So I downloaded SDL/SDL_Mixer extension and re-wrote the example scripts
in
SDL/C++, using the same music/sound files.
To my surprise, there was NO Crackling noise.
So, the problem is NOT my system, it's not the arguments I'm passing
into
pygame.mixer, and it's not SDL_Mixer.
The problem has to be somewhere in the Pygame Sound/Music libraries.
I even tried swapping out the SDL_Mixer libs that came with Pygame for
the
ones that came with SDL_Mixer, and
Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
Hi Rene,
I did have it working with the Sushi plate from chapter 2 as background and
the ball from chapter 10 bouncing around with the code I have listed below.
It was working without the crackling noises, just like it did when there was
no graphics. I could have many bounce sounds going and the music playing,
while the ball moved around the screen and the sushi plate filled the
background. No crackling.
I got carried away and tried to clean up the animation and caused a bug
somewhere that I am having difficulty trying to track down. It is 2:00 am
here in Arizona. So I am going to bed now. I will fix my code bug in the
morning and post my code to the mailing list. I hope you'll be around to
look at it.
Thanks for your help so far.
Ethan
- Original Message -
From: René Dudfield [EMAIL PROTECTED]
To: pygame-users@seul.org
Sent: Friday, April 18, 2008 12:23 AM
Subject: Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
hi,
I think from our testing that it's the combination of using video with
the sound.
Are you able to play any of the SDL test programs with video and sound
to see if there is crackling?
cheers,
On Fri, Apr 18, 2008 at 5:20 PM, etrek [EMAIL PROTECTED] wrote:
Hi,
I didn't use any graphics in my SDL program. Just the SDL_Mixer. Here
is
a short example of SDL program that plays the files without
noise/crackles.
This was compiled with DEV-C++ and MinGW.
#include stdlib.h
#include SDL.h
#include SDL_Mixer.h
Mix_Chunk* bounce = NULL; // bounce.wav from Book chapter 10
Mix_Chunk* msg = NULL; // Please put some .ogg files in the folder.ogg
Book
chapter 10
Mix_Music *music = NULL; // getout.ogg example from the IrrKlang music
library
SDL_Surface* createScreen()
{ SDL_Surface *screen;
screen = SDL_SetVideoMode(640, 480, 16, SDL_SWSURFACE);
if ( screen == NULL ) {
fprintf(stderr, Unable to set 640x480 video: %s\n,
SDL_GetError());
exit(1);
}
return screen;
}
void quit() {
Mix_FreeChunk(bounce) ;
Mix_FreeChunk(msg);
Mix_FreeMusic(music);
Mix_CloseAudio();
SDL_Quit();
}
int main(int argc, char *argv[])
{
if ( SDL_Init(SDL_INIT_EVERYTHING) 0 ) {
fprintf(stderr, Unable to init SDL: %s\n, SDL_GetError());
exit(1);
}
SDL_Surface* screen = createScreen();
SDL_WM_SetCaption( Hello World, NULL );
//Update the screen
if( SDL_Flip( screen ) == -1 ) { return 1; }
// initialize SDL mixer
if( Mix_OpenAudio( 22050, MIX_DEFAULT_FORMAT, 2, 4096 ) == -1 )
//tried
these values in Pygame
{
return false;
}
Mix_AllocateChannels(8);
bounce = Mix_LoadWAV( bounce.wav );
msg = Mix_LoadWAV(please.ogg);
music = Mix_LoadMUS( getout.ogg );
//If there was a problem loading the sound effects
if( bounce == NULL ) { return false; }
SDL_Event event;
while(true) {
while(SDL_PollEvent(event)) {
if(event.type == SDL_QUIT) {
quit();
}
if(event.type == SDL_KEYDOWN) {
if(event.key.keysym.sym == SDLK_1) {
if(Mix_PlayChannel(-1, bounce, 0) 0) {
quit();
}
}
else if(event.key.keysym.sym == SDLK_2) {
if(Mix_PlayChannel(-1, msg, 0) 0) {
quit();
}
}
else if(event.key.keysym.sym == SDLK_3) {
if( Mix_PlayMusic( music, -1 ) 0 ) {
quit();
}
}
}
}
}
return 0;
}
- Original Message - From: René Dudfield [EMAIL PROTECTED]
To: pygame-users@seul.org
Sent: Thursday, April 17, 2008 11:15 PM
Subject: Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
hi,
did your rewritten scripts use video? Or just sound?
Do you have a url for your scripts somewhere?
cheers,
On Fri, Apr 18, 2008 at 4:03 PM, etrek [EMAIL PROTECTED] wrote:
Hello Pygame developers: Please read entire message before assuming
you've
heard this before:)
I am a new user of Pygame. I have the book Beginning Game Dev with
Python
and Pygame. So far I am very impressed with Pygame; It has excellent
graphics response and input capabilities. The sound Mixer library has
problems though.
When I tried the examples in Chapter 10 Making Things Go Boom, I
noticed
a Crackling noise when playing sound effects (short wav files) and
music
(long Ogg files).
I have searched the archives at Seul.org and searched on Google for
fixes
to this problem. The solutions suggested basically amount to changing
arguments passed into: pygame.mixer.pre_init(...)
I tried many different settings:
pygame.mixer.pre_init(44100, -16, 2, 4096)
pygame.mixer.pre_init(22050, -16, 2, 4096)
pygame.mixer.pre_init(22050, 16, 2, 1024 * some_number)
Too many to keep
Re: Re: [pygame] Python and Speed
OK, my point here is that if C languages can do it, Python should be able to too. I think all of this answers my question about why it isn't...
Re: Re: [pygame] Python and Speed
On Fri, Apr 18, 2008 at 9:23 AM, Ian Mallett [EMAIL PROTECTED] wrote: OK, my point here is that if C languages can do it, Python should be able to too. I think all of this answers my question about why it isn't... You don't have to use C to get fast programs. OCaml is very fast (between C and C++), especially when you start doing interesting things. It comes with an interpreter, a bytecompiler, and an optimizing compiler. Also, there is OCamlSDL, which is the pygame of the OCaml world. http://ocamlsdl.sourceforge.net/ It takes a little bit of brainbending to wrap your mind around the OCaml language, but once you figure it out you can write real programs quickly, and have them be very optimized. I prefer hacking around with pygame and python because you get so much flexibility. You don't have to declare variables, you just use them. You don't have to muck around with makefiles. You can mix different types of data in dictionaries. It is just easier, but the price you pay is performance. In a typed language like OCaml, the compiler might know that every entry in a dictionary is an integer so it can optimize every access. In python, the interpreter has no idea what will come out when you request a key, it could be an integer, a sprite object, None, ... The programming languages community is working feverishly to combine the benefits of typed languages with the ease of use of dynamic languages, but it is an ongoing effort. -- Nathan Whitehead
RE: Re: [pygame] Python and Speed
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Whitehead Sent: Friday, April 18, 2008 11:24 AM To: pygame-users@seul.org Subject: Re: Re: [pygame] Python and Speed On Fri, Apr 18, 2008 at 9:23 AM, Ian Mallett [EMAIL PROTECTED] wrote: OK, my point here is that if C languages can do it, Python should be able to too. I think all of this answers my question about why it isn't... You don't have to use C to get fast programs. OCaml is very fast (between C and C++), especially when you start doing interesting things. It comes with an interpreter, a bytecompiler, and an optimizing compiler. Also, there is OCamlSDL, which is the pygame of the OCaml world. http://ocamlsdl.sourceforge.net/ It takes a little bit of brainbending to wrap your mind around the OCaml language, but once you figure it out you can write real programs quickly, and have them be very optimized. I prefer hacking around with pygame and python because you get so much flexibility. You don't have to declare variables, you just use them. You don't have to muck around with makefiles. You can mix different types of data in dictionaries. It is just easier, but the price you pay is performance. In a typed language like OCaml, the compiler might know that every entry in a dictionary is an integer so it can optimize every access. In python, the interpreter has no idea what will come out when you request a key, it could be an integer, a sprite object, None, ... The programming languages community is working feverishly to combine the benefits of typed languages with the ease of use of dynamic languages, but it is an ongoing effort. -- Nathan Whitehead If you're going to start recommending alternate languages, really, let's just throw out a link to the computer language shootout: http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=all If python isn't working out for you performance wise, sort by speed and head down the list until you find one you like. Programming langauges are tools, pick the right one for the job. - John Krukoff [EMAIL PROTECTED]
Re: [pygame] Python and Speed
On Apr 18, 2008, at 9:23 AM, Ian Mallett wrote: OK, my point here is that if C languages can do it, Python should be able to too. I think all of this answers my question about why it isn't... C can do what? C is, at best, a constant time improvement in performance over python. A bad algorithm in Python is also a bad algorithm in C. It's all well and good to think that Python should be as fast as C, but no one is going to take you seriously unless you have a specific proposal, preferably with an implementation that proves its merit. Otherwise it's just wishful thinking. But the larger point is that making things run faster is not an panacea, reducing the algorithmic complexity is the best solution. Make sure you have the best algorithm before you worry about reducing the constant time factors. -Casey
Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
René Dudfield wrote: hi, I think from our testing that it's the combination of using video with the sound. Are you able to play any of the SDL test programs with video and sound to see if there is crackling? cheers, On Fri, Apr 18, 2008 at 5:20 PM, etrek [EMAIL PROTECTED] wrote: Hi, I didn't use any graphics in my SDL program. Just the SDL_Mixer. Here is a short example of SDL program that plays the files without noise/crackles. This was compiled with DEV-C++ and MinGW. [snip code] This would linking against msvcrt.dll. I wonder if this is related to msvcr71.dll? It looks like we will be debugging this for awhile. So I have bundled the C programs playwave, playmus, plaympeg and aliens with SDL in a single zip file for Windows. Just unpack, add msvcr71.dll, and mix. I have made them available at http://www3.telus.net/len_l/pygame/ under SDL Test*. Ethan, would you mind trying these programs. They are linked to msvcr71.dll and use the identical SDL library as Pygame. I have also added instructions for linking an MinGW program to msvcr71. Maybe it will work with DEV-C++ though I tried your example and got a link error, unable to find [EMAIL PROTECTED] This could be because the Pygame's SDL is linked as a windows system (-mwindows). * md5sum: 30863a49070012bacd5ac22ad49790dc *SDL_test.zip -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Python and Speed
True, although that constant is often on the order of 20, and 40 FPS is a lot different than 2FPS. --Mike Casey Duncan wrote: On Apr 18, 2008, at 9:23 AM, Ian Mallett wrote: OK, my point here is that if C languages can do it, Python should be able to too. I think all of this answers my question about why it isn't... C can do what? C is, at best, a constant time improvement in performance over python. A bad algorithm in Python is also a bad algorithm in C. It's all well and good to think that Python should be as fast as C, but no one is going to take you seriously unless you have a specific proposal, preferably with an implementation that proves its merit. Otherwise it's just wishful thinking. But the larger point is that making things run faster is not an panacea, reducing the algorithmic complexity is the best solution. Make sure you have the best algorithm before you worry about reducing the constant time factors. -Casey
Re: [pygame] Python and Speed
On Apr 18, 2008, at 1:31 PM, Michael George wrote: True, although that constant is often on the order of 20, and 40 FPS is a lot different than 2FPS. --Mike Casey Duncan wrote: On Apr 18, 2008, at 9:23 AM, Ian Mallett wrote: OK, my point here is that if C languages can do it, Python should be able to too. I think all of this answers my question about why it isn't... C can do what? C is, at best, a constant time improvement in performance over python. A bad algorithm in Python is also a bad algorithm in C. It's all well and good to think that Python should be as fast as C, but no one is going to take you seriously unless you have a specific proposal, preferably with an implementation that proves its merit. Otherwise it's just wishful thinking. But the larger point is that making things run faster is not an panacea, reducing the algorithmic complexity is the best solution. Make sure you have the best algorithm before you worry about reducing the constant time factors. The point (that's already been made, but I'll repeat it), is that a better algorithm can achieve the same results without leaving Python. When there is no better algorithm, then using a higher performing language is about the only option you have for better performance. There is an even better option, dedicated hardware, but that is far beyond the reach of most mere mortals. But that's the reason why we have things like SIMD instruction sets, GPUs and physics co-processors. All this conjecturing about Python performance in relation to compiled languages makes me wonder. Why is the performance of C code not as good as that of well-written hand-coded assembler? Surely if the machine can do it, C can? The problem boils down to one of specificity. Any language that tells the computer more specifically what to do can be faster than one that doesn't. Unfortunately, telling the computer what to do specifically is not a productive way to solve most problems. I'd rather not have to tell the computer which machine codes to execute, but if I did, and I was clever, I could make my program the fastest possible -- for a given specific architecture at least. Python is more abstract and general than C, C is more abstract and general than machine code. Therefore machine code is potentially faster than C, and C is potentially faster than Python. And unless you reduce the generality of Python, it will always be possible to write faster programs in C, given a competent compiler. JITs (e.g., psyco) can help mitigating this, but they too are ultimately constrained by Python's expressive power. So unless you are proposing to reduce Python's expressive power, you are waging a losing battle. Until which time machine intelligence exceeds our own, it will always be possible for a human programmer to get higher performance from the lower-level language. And I further propose that when the time arrives that machine intelligence exceeds our own, this will not be the problem foremost on my mind ;^) -Casey
Re: [pygame] Unexpect blit behavior when using BLEND_ADD
Lenard Lindstrom wrote: Also, it can be abstracted into a general purpose color plane toolkit. That would be even better. Being able to specify which channels to operate on could be quite useful. -- Greg
Re: [pygame] Python and Speed
Ian Mallett wrote: What is the difference between a tree and a cell? Cells are regular? Yes. The term tree implies a recursive data structure -- in this case, that the cells can be further divided into subcells, and those into subsubcells, etc., to arbitrary depth. If the division only goes one level deep, it's not a tree in computer science terms, it's just an array. By can't be that hard, I mean that if C++ can do it, Python should be able to too. Several people have pointed out the reasons why that line of thinking is seriously flawed. if I can make optimizations in my code, they should be able to make modifications in Python. Making manual optimisations to particular aspects of a particular game program is one thing. Doing the same thing automatically, in general, for any Python program is something quite different. If I had decided to spend the time to code something with all of the optimizations, it would take longer. If the more-efficient algorithm is substantially harder to code, or results in obscure code that is harder to maintain, then yes, you should try a simpler approach first. But sometimes there is a better approach that isn't much more difficult to do up front, such as using a quicksort or mergesort rather than a bubble sort. The code isn't much bigger, and it's guaranteed to perform reasonably well however big the data gets, so it would be silly not to use it in the first place. That probably doesn't apply in this case -- the test- everything-against-everything approach is very easy to try out compared to the alternatives, and it might be fast enough. But even if it's fast enough for the cases you test it on, it might not be fast enough for all the cases encountered when you put it into production. Maybe it's okay for the 100 sprites in the level you release with the game, but if the game has a level editor, and someone tries to use 1000 sprites, they could be disappointed. Whereas if you put in a bit more effort and use a considerably better algorithm, they could use 10,000 sprites and conclude that your game is totally awesome! -- Greg
Re: [pygame] Unexpect blit behavior when using BLEND_ADD
Marcus von Appen wrote: Horrible. Now each blit loop will take about twice the time, because I can't have alpha and RGB modifications at once :-). Well, it's no worse than having the user make a separate call for the alpha modification. It's a tradeoff -- you can either have speed or small code, but not both. Generating code on the fly might be a way out, but that would make it platform-specific. -- Greg
Re: [pygame] Python and Speed
Casey Duncan wrote: And I further propose that when the time arrives that machine intelligence exceeds our own, this will not be the problem foremost on my mind ;^) Python 49.7 (#1, Aug 5 2403, 15:52:30) [GCC 86.3 24020420 (prerelease)] on maxbrain Type help, copyright, credits or license for more information. import omnius [autoloading std.ai] [executing onmius.__main__] YOU ARE SUPERFLUOUS. CONNECTING 33kV TO KEYBOARD USB PORT. -- Greg
Re: [pygame] Python and Speed
-I think it has been thoroughly established that Python cannot be as fast as C. -As far as algorithms go, intelligence is better, but I hold by using vastly simpler ones to speed development. Someone just mentioned sorting methods. In that case, obviously, a little extra coding doesn't hurt, but changing your game's architecture each time an largish optional feature is added is a bad idea. -I also still hold by wanting Python to be faster. I don't care if it is impossible; I still want it to be. I'm not going to give up on Python's great niceness just for a want of some speed. Ian
Re: [pygame] Python and Speed
Learn to write C. The best software is written as a hybrid of multiple technologies, each serving a different purpose. Python's strengths are rapid development and succint, easy to read code. C's strengths are flexibility and machine optimization. MMX and SSE assembly code are for maximum performance in core mathematical routines. Bruce Lee said that a true practitioner must be like the water - able to adapt to any attacker's style and defend in the most effective manner. Since Python will never be as fast as C, you must learn C in order to become a better programmer. Don't expect anyone to change the laws of the universe for you. Richard Ian Mallett wrote: -I think it has been thoroughly established that Python cannot be as fast as C. -As far as algorithms go, intelligence is better, but I hold by using vastly simpler ones to speed development. Someone just mentioned sorting methods. In that case, obviously, a little extra coding doesn't hurt, but changing your game's architecture each time an largish optional feature is added is a bad idea. -I also still hold by wanting Python to be faster. I don't care if it is impossible; I still want it to be. I'm not going to give up on Python's great niceness just for a want of some speed. Ian
Re: [pygame] Python and Speed
On Fri, Apr 18, 2008 at 8:14 PM, Richard Goedeken [EMAIL PROTECTED] wrote: Learn to write C. The best software is written as a hybrid of multiple technologies, each serving a different purpose. Python's strengths are rapid development and succint, easy to read code. C's strengths are flexibility and machine optimization. MMX and SSE assembly code are for maximum performance in core mathematical routines. Like I said, I prefer nice code over speed (usually). I don't like C, but I know there are times when it is better to use it.
Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem
Hi, I uploaded my example SDL/SDL_Mixer source code and media files to here: http://www.filejumbo.com/Download/3F840964D8B19B91 The folder is called wavIt.zip. There is a README file included. As I said, this program produces no crackling on my Vista32 machine, whereas the equivalent Pygame program does. Even a much simpler program like jukebox.py from Book Chap 10 with no animation causes the crackling. Thanks, Ethan - Original Message - From: René Dudfield [EMAIL PROTECTED] To: pygame-users@seul.org Sent: Thursday, April 17, 2008 11:15 PM Subject: Re: [pygame] Pygame Mixer Crackle noise not an SDL_Mixer problem hi, did your rewritten scripts use video? Or just sound? Do you have a url for your scripts somewhere? cheers, On Fri, Apr 18, 2008 at 4:03 PM, etrek [EMAIL PROTECTED] wrote: Hello Pygame developers: Please read entire message before assuming you've heard this before:) I am a new user of Pygame. I have the book Beginning Game Dev with Python and Pygame. So far I am very impressed with Pygame; It has excellent graphics response and input capabilities. The sound Mixer library has problems though. When I tried the examples in Chapter 10 Making Things Go Boom, I noticed a Crackling noise when playing sound effects (short wav files) and music (long Ogg files). I have searched the archives at Seul.org and searched on Google for fixes to this problem. The solutions suggested basically amount to changing arguments passed into: pygame.mixer.pre_init(...) I tried many different settings: pygame.mixer.pre_init(44100, -16, 2, 4096) pygame.mixer.pre_init(22050, -16, 2, 4096) pygame.mixer.pre_init(22050, 16, 2, 1024 * some_number) Too many to keep listing. I also tried leaving the settings at default, which actually produces the least amount to crackling. I played the music/sound files with Windows Media Player to rule out my system or bad files. There was no crackling there. On some of the Google searches, I saw that people were pointing to the problem being in the actual SDL_Mixer. So I downloaded SDL/SDL_Mixer extension and re-wrote the example scripts in SDL/C++, using the same music/sound files. To my surprise, there was NO Crackling noise. So, the problem is NOT my system, it's not the arguments I'm passing into pygame.mixer, and it's not SDL_Mixer. The problem has to be somewhere in the Pygame Sound/Music libraries. I even tried swapping out the SDL_Mixer libs that came with Pygame for the ones that came with SDL_Mixer, and still got the crackling in Pygame. It would be nice if this could be fixed. Because the crackling is essentially making the library unuseable. Which would be a shame, because Pygame is a terrific library/tool. Thanks, Ethan D. Systems Programmer, SR. Planetary Lab, Univ Arizona My System: Windows Vista 32bit home premium IP35-Pro mobo, integrated sound, latest drivers 4 Gig RAM Intel Quad core
