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 prog
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
>
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 pe
-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 c
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 "li
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 cod
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 go
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
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
Hi!
I guess we could talk any language to death on speed, but being smart on
how to speed up the existing one is the best approach.
As I said, Ian could use the example I gave him and the other comments
which he has already said he does. The distance instead of the square root
for that is
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 quest
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,
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 algor
> -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]> wro
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
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...
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 t
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 graph
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
#include
#include
Mix_Chunk* bounce = NULL; // bounce.wav from Book chapter 10
Mix_
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 uncontrolla
20 matches
Mail list logo
