Re: [pygame] Incrementing the frequency of the Pygame.mixer with a Loop?

[Lenard Lindstrom]

Hi Brian,

You would probably have to do a pygame.quit rather than 
pygame.mixer.quit for each pass of the loop. The pgyame.display.set_mode 
must also come after the pygame.init. The display is not necessary for 
mixer though.


Lenard

Brian Gryder wrote:

'''
How do I change the frequency of the Pygame.mixer by incrementing the 
frequency value in a loop?


Please see the example below where I am trying to initialize the 
frequency at 44100 and then add 2000 to the frequency each time it 
loops. In this example below the pitch does not change, I really want 
it to change.


Any links or snippet of code would be greatly appreciated, Thanks!
 
'''


import pygame
from pygame.locals import *
from sys import exit

screen = pygame.display.set_mode((800, 600), 0, 32)
frequency = 44100

while True:

frequency = frequency + 2000
print frequency

pygame.mixer.pre_init(frequency, 16, 2, 4096)
pygame.init()
test_sound = ""
test_sound = pygame.mixer.Sound("check.wav")
mychannel = test_sound.play()

while pygame.mixer.get_busy() == True:
pass
#"passing"

pygame.mixer.quit

Re: [pygame] Color slice problem with Python 3

[René Dudfield]

 Sweet.  That works for py3k.

Committed revision 2488.

cu,

[pygame] Incrementing the frequency of the Pygame.mixer with a Loop?

[Brian Gryder]

'''
How do I change the frequency of the Pygame.mixer by incrementing the
frequency value in a loop?

Please see the example below where I am trying to initialize the frequency
at 44100 and then add 2000 to the frequency each time it loops. In this
example below the pitch does not change, I really want it to change.

Any links or snippet of code would be greatly appreciated, Thanks!

'''

import pygame
from pygame.locals import *
from sys import exit

screen = pygame.display.set_mode((800, 600), 0, 32)
frequency = 44100

while True:

frequency = frequency + 2000
print frequency

pygame.mixer.pre_init(frequency, 16, 2, 4096)
pygame.init()
test_sound = ""
test_sound = pygame.mixer.Sound("check.wav")
mychannel = test_sound.play()

while pygame.mixer.get_busy() == True:
pass
#"passing"

pygame.mixer.quit

Re: [pygame] 7 failures and 1 error in test suite

[René Dudfield]

On Tue, Jul 7, 2009 at 9:28 PM,  wrote:

> Hi,
>
> I'm getting the feeling that either there are quite some bugs in the
> surface_test code or that I don't get what's going on.
>
> first I looked at the failing test I mentioned before (~line 104):
>
>def make_surf(bpp, flags, masks):
>pygame.Surface((10, 10), flags, bpp, masks)
> self.failUnlessRaises(ValueError, make_surf, 32, 0,
>   (0xFF00, 0xFF, 0xFF00, 0))
>
> and saw no good reason why the call to make_surf should raise an
> ValueError.
> Please tell me if I'm wrong here.
>

I don't understand why either?



>
> So then I thought maybe it's not a bug with 64-bit machines but rather with
> 32-bit ones and indeed I found a suspicious piece of code in base.c (line
> 335):
>
>*val = (Uint32) PyInt_AsLong (intobj);
>
> if the intobj is negative (like 0xFF00) the result won't be as desired.
> I changed that function (UintFromObj) to use a PyLong instead of a PyInt
> and then call PyLong_AsUnsignedLong (patch attached).
>

Yeah, that seems sensible.  It should really be called Uint32FromObj.



>
> Again: If my assumption that the unit test should not raise that ValueError
> is wrong this might be a moot point.
>
> with this patch applied the ValueError is not raised but then two other
> test in surface_test.py fail. namely test_blit_blend_rgba and
> test_blit_blend.
>
> I first looked into test_blit_blend_rgba and found the function
> surf_get_masks to be questionable. the Py_BuildValue uses "i" as format
> characters which represent ints using "I" for unsigned int makes the Error
> go away (patch attached).
>

sounds good.



>
> last but not least test_blit_blend. My suspicion is that the intify helper
> function screws things up. I also attached a patch with my idea of an intify
> function.
>
> with all the patches applied all test pass except for test_flags (because
> of the UintFromObj.patch) so I also attached a patch which fixes the test
> (and renames it to test_masks because that is what is tested and not the
> flags.
>
>
again looks good.


>
> Note that I didn't test these patches on my 64-bit machine yet.
> I'll let you know as soon as I've done so.
>
> Please let me know if I got something wrong.
>
>
> yours
> //Lorenz
>
>
>

Committed revision 2486.


cheers!

Re: [pygame] being at pygame-users group without receiving mails in our inbox

[Paulo Silva]

thanks, i didn't knew about filters, and how to use them - let's see
how fine it works! thanks! :)

On 7/7/09, Nirav Patel  wrote:
> I don't know about using Google Groups, but I see you are using Gmail.
>  Why not create a filter that adds a List or Pygame label to mailing
> list messages, removes them from the inbox, and maybe marks them as
> read?  Labels and filters make gmail great for following mailing lists
> without crowding your inbox.  Plus, with 7GB+ of space, I don't think
> you need to worry about <1MB a month of mailing list traffic.
>
> http://mail.google.com/support/bin/topic.py?hl=en&topic=12881
>
> Nirav
>
> On Tue, Jul 7, 2009 at 11:54 AM, Paulo Silva wrote:
>> Hi!
>>
>> since i used to follow pygame-users mailing list from google groups,
>> is that possible sending messages to there, and not receiving anyone
>> in your mail inbox? if it is, where must we configure, by webpage
>> configuring or mailing list commands?
>>
>> what google groups is awesome is exactly this feature, making us able
>> to post messages in a mailing list, seeing which mailing list messages
>> were sent there, and not having the worry of loosing time deleting
>> every message from our mail account inbox
>>
>> i'm asking this because it's very boring having to subscribe and
>> unsubscribe all the time we want to send messages to this mailing
>> list...
>>
>> thanks! :)
>>
>

Re: [pygame] being at pygame-users group without receiving mails in our inbox

[Nirav Patel]

I don't know about using Google Groups, but I see you are using Gmail.
 Why not create a filter that adds a List or Pygame label to mailing
list messages, removes them from the inbox, and maybe marks them as
read?  Labels and filters make gmail great for following mailing lists
without crowding your inbox.  Plus, with 7GB+ of space, I don't think
you need to worry about <1MB a month of mailing list traffic.

http://mail.google.com/support/bin/topic.py?hl=en&topic=12881

Nirav

On Tue, Jul 7, 2009 at 11:54 AM, Paulo Silva wrote:
> Hi!
>
> since i used to follow pygame-users mailing list from google groups,
> is that possible sending messages to there, and not receiving anyone
> in your mail inbox? if it is, where must we configure, by webpage
> configuring or mailing list commands?
>
> what google groups is awesome is exactly this feature, making us able
> to post messages in a mailing list, seeing which mailing list messages
> were sent there, and not having the worry of loosing time deleting
> every message from our mail account inbox
>
> i'm asking this because it's very boring having to subscribe and
> unsubscribe all the time we want to send messages to this mailing
> list...
>
> thanks! :)
>

Re: [pygame] sprites in arrays, instead of simple variables

[Paulo Silva]

@TyleLaing

but do you know where can i find working snippets with sprite groups,
like this one i sent? http://pastebin.com/f2b05bf70

(or how sprite group classes can be easily implemented there, if you
or someone don't mind... :| )

thanks a lot! :)

On 7/7/09, Paulo Silva  wrote:
> thanks! :)
>
> On 7/7/09, Tyler Laing  wrote:
>> Hi,
>>
>> Take a look at the group classes. This lets you manage the sprites
>> easily.
>>
>> http://www.pygame.org/docs/ref/sprite.html#pygame.sprite.Group
>>
>> -Tyler
>>
>> On Tue, Jul 7, 2009 at 8:55 AM, Paulo Silva 
>> wrote:
>>
>>> hi!
>>> recently i coded this humble snipped using sprites from subsurfaces:
>>> http://pastebin.com/f2b05bf70
>>>
>>> the question is: it seems to be simple working with just 4 different
>>> sprites, one in each variable - but when they are hundreds or
>>> thousands, this task become to be very boring - can we store sprites
>>> into arrays instead of simple variables?
>>>
>>> another question: this example became slow when the ammount of sprites
>>> on screen are 256 or more, on a Pentium4-sse2 (i'm using Ubuntu Linux
>>> 9.04) - is there some way to speed up this task, and allowing as much
>>> as 1000 sprites or more for this? (i'm interested on trying to start
>>> coding those bullet-hell doujin shumps, and this snippet were for
>>> testing how many sprites we can count with for this kind of game
>>> development)
>>>
>>> thanks! :)
>>>
>>
>>
>>
>> --
>> Visit my blog at http://oddco.ca/zeroth/zblog
>>
>

Re: [pygame] sprites in arrays, instead of simple variables

[Paulo Silva]

thanks! :)

On 7/7/09, Tyler Laing  wrote:
> Hi,
>
> Take a look at the group classes. This lets you manage the sprites easily.
>
> http://www.pygame.org/docs/ref/sprite.html#pygame.sprite.Group
>
> -Tyler
>
> On Tue, Jul 7, 2009 at 8:55 AM, Paulo Silva  wrote:
>
>> hi!
>> recently i coded this humble snipped using sprites from subsurfaces:
>> http://pastebin.com/f2b05bf70
>>
>> the question is: it seems to be simple working with just 4 different
>> sprites, one in each variable - but when they are hundreds or
>> thousands, this task become to be very boring - can we store sprites
>> into arrays instead of simple variables?
>>
>> another question: this example became slow when the ammount of sprites
>> on screen are 256 or more, on a Pentium4-sse2 (i'm using Ubuntu Linux
>> 9.04) - is there some way to speed up this task, and allowing as much
>> as 1000 sprites or more for this? (i'm interested on trying to start
>> coding those bullet-hell doujin shumps, and this snippet were for
>> testing how many sprites we can count with for this kind of game
>> development)
>>
>> thanks! :)
>>
>
>
>
> --
> Visit my blog at http://oddco.ca/zeroth/zblog
>

[pygame] sprites in arrays instead of

[nitrofurano]

hi!
recently i coded this humble snipped using sprites from subsurfaces:
http://pastebin.com/f2b05bf70

the question is: it seems to be simple working with just 4 different
sprites, one in each variable - but when they are hundreds or
thousands, this task become to be very boring - can we store sprites
into arrays instead of simple variables?

another question: this example became slow when the ammount of sprites
on screen are 256 or more, on a Pentium4-sse2 (i'm using Ubuntu Linux
9.04) - is there some way to speed up this task, and allowing as much
as 1000 sprites or more for this? (i'm interested on trying to start
coding those bullet-hell doujin shumps, and this snippet were for
testing how many sprites we can count with for this kind of game
development)

thanks! :)

[pygame] [patch] minor fix to surface docs

[Lorenz Quack]

Hi,

here is a minor patch to the surface docs.

//Lorenz
Index: src/surface.doc
===
--- src/surface.doc (revision 2482)
+++ src/surface.doc (working copy)
@@ -28,8 +28,9 @@
 
 Surfaces can have many extra attributes like alpha planes, colorkeys, source
 rectangle clipping. These functions mainly effect how the Surface is blitted
-to other Surfaces. The blit routines will attempt to use hardware acceleratio
- when possible, otherwise will use highly optimized software blitting methods.
+to other Surfaces. The blit routines will attempt to use hardware acceleration
+when possible, otherwise they will use highly optimized software blitting
+methods.
 
 There are three types of transparency supported in Pygame: colorkeys, 
 surface alphas, and pixel alphas. Surface alphas can be mixed with colorkeys,
Index: docs/ref/surface.html
===
--- docs/ref/surface.html   (revision 2482)
+++ docs/ref/surface.html   (working copy)
@@ -109,9 +109,8 @@
   SRCALPHA, the pixel format will include a per-pixel alpha
 Both flags are only a request, and may not be possible for all 
displays and formats. 
 Advance users can combine a set of bitmasks with a depth value. The masks 
are a set of 4 integers representing which bits in a pixel will represent each 
color. Normal Surfaces should not require the masks argument. 
-Surfaces can have many extra attributes like alpha planes, colorkeys, 
source rectangle clipping. These functions mainly effect how the Surface is 
blitted to other Surfaces. The blit routines will attempt to use hardware 
acceleratio 
- when possible, otherwise will use highly optimized software blitting 
methods.
-There are three types of transparency supported in Pygame: colorkeys, 
surface alphas, and pixel alphas. Surface alphas can be mixed with colorkeys, 
but an image with per pixel alphas cannot use the other modes. Colorkey 
transparency makes a single color value transparent. Any pixels matching the 
colorkey will not be drawn. The surface alpha value is a single value that 
changes the transparency for the entire image. A surface alpha of 255 
is opaque, and a value of 0 is completely transparent. 
+Surfaces can have many extra attributes like alpha planes, colorkeys, 
source rectangle clipping. These functions mainly effect how the Surface is 
blitted to other Surfaces. The blit routines will attempt to use hardware 
acceleration when possible, otherwise they will use highly optimized software 
blitting methods. 
+There are three types of transparency supported in Pygame: colorkeys, 
surface alphas, and pixel alphas. Surface alphas can be mixed with colorkeys, 
but an image with per pixel alphas cannot use the other modes. Colorkey 
transparency makes a single color value transparent. Any pixels matching the 
colorkey will not be drawn. The surface alpha value is a single value that 
changes the transparency for the entire image. A surface alpha of 255 
is opaque, and a value of 0 is completely transparent. 
 Per pixel alphas are different because they store a transparency value for 
every pixel. This allows for the most precise transparency effects, but it also 
the slowest. Per pixel alphas cannot be mixed with surface alpha and colorkeys. 

 There is support for pixel access for the Surfaces. Pixel access on 
hardware surfaces is slow and not recommended. Pixels can be accessed using the 
get_at() and set_at() functions. These methods are fine for simple access, but 
will be considerably slow when doing of pixel work with them. If you plan on 
doing a lot of pixel level work, it is recommended to use the 
pygame.surfarray module, which can treat the surfaces like large 
multidimensional arrays (and it's quite quick). 
 Any functions that directly access a surface's pixel data will need that 
surface to be lock()'ed. These functions can lock() and unlock() the surfaces 
themselves without assistance. But, if a function will be called many times, 
there will be a lot of overhead for multiple locking and unlocking of the 
surface. It is best to lock the surface manually before making the function 
call many times, and then unlocking when you are finished. All functions that 
need a locked surface will say so in their docs. Remember to leave the Surface 
locked only while necessary. 

Re: [pygame] sprites in arrays, instead of simple variables

[Tyler Laing]

Hi,

Take a look at the group classes. This lets you manage the sprites easily.

http://www.pygame.org/docs/ref/sprite.html#pygame.sprite.Group

-Tyler

On Tue, Jul 7, 2009 at 8:55 AM, Paulo Silva  wrote:

> hi!
> recently i coded this humble snipped using sprites from subsurfaces:
> http://pastebin.com/f2b05bf70
>
> the question is: it seems to be simple working with just 4 different
> sprites, one in each variable - but when they are hundreds or
> thousands, this task become to be very boring - can we store sprites
> into arrays instead of simple variables?
>
> another question: this example became slow when the ammount of sprites
> on screen are 256 or more, on a Pentium4-sse2 (i'm using Ubuntu Linux
> 9.04) - is there some way to speed up this task, and allowing as much
> as 1000 sprites or more for this? (i'm interested on trying to start
> coding those bullet-hell doujin shumps, and this snippet were for
> testing how many sprites we can count with for this kind of game
> development)
>
> thanks! :)
>



-- 
Visit my blog at http://oddco.ca/zeroth/zblog

[pygame] sprites in arrays, instead of simple variables

[Paulo Silva]

hi!
recently i coded this humble snipped using sprites from subsurfaces:
http://pastebin.com/f2b05bf70

the question is: it seems to be simple working with just 4 different
sprites, one in each variable - but when they are hundreds or
thousands, this task become to be very boring - can we store sprites
into arrays instead of simple variables?

another question: this example became slow when the ammount of sprites
on screen are 256 or more, on a Pentium4-sse2 (i'm using Ubuntu Linux
9.04) - is there some way to speed up this task, and allowing as much
as 1000 sprites or more for this? (i'm interested on trying to start
coding those bullet-hell doujin shumps, and this snippet were for
testing how many sprites we can count with for this kind of game
development)

thanks! :)

[pygame] being at pygame-users group without receiving mails in our inbox

[Paulo Silva]

Hi!

since i used to follow pygame-users mailing list from google groups,
is that possible sending messages to there, and not receiving anyone
in your mail inbox? if it is, where must we configure, by webpage
configuring or mailing list commands?

what google groups is awesome is exactly this feature, making us able
to post messages in a mailing list, seeing which mailing list messages
were sent there, and not having the worry of loosing time deleting
every message from our mail account inbox

i'm asking this because it's very boring having to subscribe and
unsubscribe all the time we want to send messages to this mailing
list...

thanks! :)

Re: [pygame] 7 failures and 1 error in test suite

[Lorenz Quack]

Update: Patches work fine on my 64-bit machine.


d...@amberfisharts.com wrote:

Hm...
the last attachment didn't make it in. here it is.



On Tue, 7 Jul 2009 13:28:18 +0200,  wrote:

Hi,

I'm getting the feeling that either there are quite some bugs in the
surface_test code or that I don't get what's going on.

first I looked at the failing test I mentioned before (~line 104):

def make_surf(bpp, flags, masks):
pygame.Surface((10, 10), flags, bpp, masks)
self.failUnlessRaises(ValueError, make_surf, 32, 0,
  (0xFF00, 0xFF, 0xFF00, 0))

and saw no good reason why the call to make_surf should raise an
ValueError.
Please tell me if I'm wrong here.

So then I thought maybe it's not a bug with 64-bit machines but rather
with 32-bit ones and indeed I found a suspicious piece of code in base.c
(line 335):

*val = (Uint32) PyInt_AsLong (intobj);

if the intobj is negative (like 0xFF00) the result won't be as
desired.
I changed that function (UintFromObj) to use a PyLong instead of a PyInt
and then call PyLong_AsUnsignedLong (patch attached).

Again: If my assumption that the unit test should not raise that
ValueError is wrong this might be a moot point.

with this patch applied the ValueError is not raised but then two other
test in surface_test.py fail. namely test_blit_blend_rgba and
test_blit_blend.

I first looked into test_blit_blend_rgba and found the function
surf_get_masks to be questionable. the Py_BuildValue uses "i" as format
characters which represent ints using "I" for unsigned int makes the Error
go away (patch attached).

last but not least test_blit_blend. My suspicion is that the intify helper
function screws things up. I also attached a patch with my idea of an
intify function.

with all the patches applied all test pass except for test_flags (because
of the UintFromObj.patch) so I also attached a patch which fixes the test
(and renames it to test_masks because that is what is tested and not the
flags.


Note that I didn't test these patches on my 64-bit machine yet.
I'll let you know as soon as I've done so.

Please let me know if I got something wrong.


yours
//Lorenz



On Tue, 07 Jul 2009 00:40:39 +0200, Lorenz Quack 
wrote:

Hi,

yup. the color test now pass.
the failing midi is not really a bug as I don't have portmidi.
I haven't looked into the failing surface test, yet.



René Dudfield wrote:

Hi,

the Color 64bit errors are fixed.  A combination of testing against
LONG_MAX, and using Uint32.

Committed revision 2472.

cheers,


On Thu, Jul 2, 2009 at 11:52 PM, Hugo Arts mailto:hugo.yo...@gmail.com>> wrote:

On Thu, Jul 2, 2009 at 2:55 PM, mailto:d...@amberfisharts.com>> wrote:
 >
 > Hi,
 >
 > On Thu, 2 Jul 2009 09:48:48 +1000, René Dudfield
mailto:ren...@gmail.com>> wrote:
 >> Cool, thanks for the testing.
 >>
 >>
 >> On Thu, Jul 2, 2009 at 9:19 AM, Lorenz
Quackmailto:d...@amberfisharts.com>> wrote:
 >>> Ok, so here goes my analysis of the failures in ColorTypeTest:
 >>> In src/color.c line 1435 (and some following lines) we bit
shift each
 >> color
 >>> component and stuff them
 >>> in an unsigned long.
 >>
 >> Maybe this should be into a uint32 instead?
 >>
 >
 > Yes, that would correspond to my solution 1) only better because
it ensures that it will have exactly 32 bit.
 > BTW, are these types uint32, UInt8, ... in the C-standard?
 >
 > yours
 > //Lorenz
 >

No. ANSI C only defines the char, int, float, and double types,

along

with the short/long and signed/unsigned modifiers.
The sizes of these types are not defined in the standard. ANSI only
gives some minimum sizes, and mandates that

short int <= int <= long int
float <= double <= long double

So, in theory, the size of your int type is completely platform
dependent. In practice nearly every modern compiler uses the same
sizes,
char = 8, int = 32, float = 32, double = 64, but there are some
differences between 32bit and 64bit architectures (e.g. long int is
usually the same size as int on 32bit). Hence the often defined
uint32, uint8 etc. types.

See also http://en.wikipedia.org/wiki/C_data_types

Hugo


>

Re: [pygame] 7 failures and 1 error in test suite

[don]

Hm...
the last attachment didn't make it in. here it is.



On Tue, 7 Jul 2009 13:28:18 +0200,  wrote:
> Hi,
> 
> I'm getting the feeling that either there are quite some bugs in the
> surface_test code or that I don't get what's going on.
> 
> first I looked at the failing test I mentioned before (~line 104):
> 
> def make_surf(bpp, flags, masks):
> pygame.Surface((10, 10), flags, bpp, masks)
> self.failUnlessRaises(ValueError, make_surf, 32, 0,
>   (0xFF00, 0xFF, 0xFF00, 0))
> 
> and saw no good reason why the call to make_surf should raise an
> ValueError.
> Please tell me if I'm wrong here.
> 
> So then I thought maybe it's not a bug with 64-bit machines but rather
> with 32-bit ones and indeed I found a suspicious piece of code in base.c
> (line 335):
> 
> *val = (Uint32) PyInt_AsLong (intobj);
> 
> if the intobj is negative (like 0xFF00) the result won't be as
> desired.
> I changed that function (UintFromObj) to use a PyLong instead of a PyInt
> and then call PyLong_AsUnsignedLong (patch attached).
> 
> Again: If my assumption that the unit test should not raise that
> ValueError is wrong this might be a moot point.
> 
> with this patch applied the ValueError is not raised but then two other
> test in surface_test.py fail. namely test_blit_blend_rgba and
> test_blit_blend.
> 
> I first looked into test_blit_blend_rgba and found the function
> surf_get_masks to be questionable. the Py_BuildValue uses "i" as format
> characters which represent ints using "I" for unsigned int makes the Error
> go away (patch attached).
> 
> last but not least test_blit_blend. My suspicion is that the intify helper
> function screws things up. I also attached a patch with my idea of an
> intify function.
> 
> with all the patches applied all test pass except for test_flags (because
> of the UintFromObj.patch) so I also attached a patch which fixes the test
> (and renames it to test_masks because that is what is tested and not the
> flags.
> 
> 
> Note that I didn't test these patches on my 64-bit machine yet.
> I'll let you know as soon as I've done so.
> 
> Please let me know if I got something wrong.
> 
> 
> yours
> //Lorenz
> 
> 
> 
> On Tue, 07 Jul 2009 00:40:39 +0200, Lorenz Quack 
> wrote:
>> Hi,
>>
>> yup. the color test now pass.
>> the failing midi is not really a bug as I don't have portmidi.
>> I haven't looked into the failing surface test, yet.
>>
>>
>>
>> René Dudfield wrote:
>>> Hi,
>>>
>>> the Color 64bit errors are fixed.  A combination of testing against
>>> LONG_MAX, and using Uint32.
>>>
>>> Committed revision 2472.
>>>
>>> cheers,
>>>
>>>
>>> On Thu, Jul 2, 2009 at 11:52 PM, Hugo Arts >> > wrote:
>>>
>>> On Thu, Jul 2, 2009 at 2:55 PM, >> > wrote:
>>>  >
>>>  > Hi,
>>>  >
>>>  > On Thu, 2 Jul 2009 09:48:48 +1000, René Dudfield
>>> mailto:ren...@gmail.com>> wrote:
>>>  >> Cool, thanks for the testing.
>>>  >>
>>>  >>
>>>  >> On Thu, Jul 2, 2009 at 9:19 AM, Lorenz
>>> Quackmailto:d...@amberfisharts.com>> wrote:
>>>  >>> Ok, so here goes my analysis of the failures in ColorTypeTest:
>>>  >>> In src/color.c line 1435 (and some following lines) we bit
>>> shift each
>>>  >> color
>>>  >>> component and stuff them
>>>  >>> in an unsigned long.
>>>  >>
>>>  >> Maybe this should be into a uint32 instead?
>>>  >>
>>>  >
>>>  > Yes, that would correspond to my solution 1) only better because
>>> it ensures that it will have exactly 32 bit.
>>>  > BTW, are these types uint32, UInt8, ... in the C-standard?
>>>  >
>>>  > yours
>>>  > //Lorenz
>>>  >
>>>
>>> No. ANSI C only defines the char, int, float, and double types,
>> along
>>> with the short/long and signed/unsigned modifiers.
>>> The sizes of these types are not defined in the standard. ANSI only
>>> gives some minimum sizes, and mandates that
>>>
>>> short int <= int <= long int
>>> float <= double <= long double
>>>
>>> So, in theory, the size of your int type is completely platform
>>> dependent. In practice nearly every modern compiler uses the same
>>> sizes,
>>> char = 8, int = 32, float = 32, double = 64, but there are some
>>> differences between 32bit and 64bit architectures (e.g. long int is
>>> usually the same size as int on 32bit). Hence the often defined
>>> uint32, uint8 etc. types.
>>>
>>> See also http://en.wikipedia.org/wiki/C_data_types
>>>
>>> Hugo
>>>
>>>

test_flags.patch
Description: Binary data

Re: [pygame] 7 failures and 1 error in test suite

[don]

Hi,

I'm getting the feeling that either there are quite some bugs in the 
surface_test code or that I don't get what's going on.

first I looked at the failing test I mentioned before (~line 104):

def make_surf(bpp, flags, masks):
pygame.Surface((10, 10), flags, bpp, masks)
self.failUnlessRaises(ValueError, make_surf, 32, 0, 
  (0xFF00, 0xFF, 0xFF00, 0))

and saw no good reason why the call to make_surf should raise an ValueError.
Please tell me if I'm wrong here.

So then I thought maybe it's not a bug with 64-bit machines but rather with 
32-bit ones and indeed I found a suspicious piece of code in base.c (line 335):

*val = (Uint32) PyInt_AsLong (intobj);

if the intobj is negative (like 0xFF00) the result won't be as desired.
I changed that function (UintFromObj) to use a PyLong instead of a PyInt and 
then call PyLong_AsUnsignedLong (patch attached).

Again: If my assumption that the unit test should not raise that ValueError is 
wrong this might be a moot point.

with this patch applied the ValueError is not raised but then two other test in 
surface_test.py fail. namely test_blit_blend_rgba and test_blit_blend.

I first looked into test_blit_blend_rgba and found the function surf_get_masks 
to be questionable. the Py_BuildValue uses "i" as format characters which 
represent ints using "I" for unsigned int makes the Error go away (patch 
attached).

last but not least test_blit_blend. My suspicion is that the intify helper 
function screws things up. I also attached a patch with my idea of an intify 
function.

with all the patches applied all test pass except for test_flags (because of 
the UintFromObj.patch) so I also attached a patch which fixes the test (and 
renames it to test_masks because that is what is tested and not the flags.


Note that I didn't test these patches on my 64-bit machine yet.
I'll let you know as soon as I've done so.

Please let me know if I got something wrong.


yours
//Lorenz



On Tue, 07 Jul 2009 00:40:39 +0200, Lorenz Quack  wrote:
> Hi,
> 
> yup. the color test now pass.
> the failing midi is not really a bug as I don't have portmidi.
> I haven't looked into the failing surface test, yet.
> 
> 
> 
> René Dudfield wrote:
>> Hi,
>>
>> the Color 64bit errors are fixed.  A combination of testing against
>> LONG_MAX, and using Uint32.
>>
>> Committed revision 2472.
>>
>> cheers,
>>
>>
>> On Thu, Jul 2, 2009 at 11:52 PM, Hugo Arts > > wrote:
>>
>> On Thu, Jul 2, 2009 at 2:55 PM, > > wrote:
>>  >
>>  > Hi,
>>  >
>>  > On Thu, 2 Jul 2009 09:48:48 +1000, René Dudfield
>> mailto:ren...@gmail.com>> wrote:
>>  >> Cool, thanks for the testing.
>>  >>
>>  >>
>>  >> On Thu, Jul 2, 2009 at 9:19 AM, Lorenz
>> Quackmailto:d...@amberfisharts.com>> wrote:
>>  >>> Ok, so here goes my analysis of the failures in ColorTypeTest:
>>  >>> In src/color.c line 1435 (and some following lines) we bit
>> shift each
>>  >> color
>>  >>> component and stuff them
>>  >>> in an unsigned long.
>>  >>
>>  >> Maybe this should be into a uint32 instead?
>>  >>
>>  >
>>  > Yes, that would correspond to my solution 1) only better because
>> it ensures that it will have exactly 32 bit.
>>  > BTW, are these types uint32, UInt8, ... in the C-standard?
>>  >
>>  > yours
>>  > //Lorenz
>>  >
>>
>> No. ANSI C only defines the char, int, float, and double types,
> along
>> with the short/long and signed/unsigned modifiers.
>> The sizes of these types are not defined in the standard. ANSI only
>> gives some minimum sizes, and mandates that
>>
>> short int <= int <= long int
>> float <= double <= long double
>>
>> So, in theory, the size of your int type is completely platform
>> dependent. In practice nearly every modern compiler uses the same
>> sizes,
>> char = 8, int = 32, float = 32, double = 64, but there are some
>> differences between 32bit and 64bit architectures (e.g. long int is
>> usually the same size as int on 32bit). Hence the often defined
>> uint32, uint8 etc. types.
>>
>> See also http://en.wikipedia.org/wiki/C_data_types
>>
>> Hugo
>>
>>

UintFromObj.patch
Description: Binary data


surf_get_masks.patch
Description: Binary data


intify.patch
Description: Binary data