Re: [pygame] BUG:? color incompatibility in pygame 1.8.1release versus 1.7.1release
Regardless of backwards compatibility issues, having a default alpha value of 0 just seems completely wrong to me, and completely non-intuitive. largely because in a 24-bit context (like on the web), I would always be writing #RRGGBB, and would never even consider adding in an alpha. So my brain has naturally gotten a lot of experience associating specifying RGB with no A as meaning a solid color. meaning I would definitely say having a default alpha of 0 in any case is a bug. period. On Sun, Aug 17, 2008 at 7:45 PM, Nicholas Dudfield [EMAIL PROTECTED]wrote: I will update the tests. If the new Color.__doc__ claims case insensitivity then I will put in a failing test. The author of the module wrote some tests for webstyle arguments to the Color constructor that explicitly tested for 0 as the default alpha so I'm not sure there. Actually there seems to be some internal inconsistencies as: In [2]: pygame.Color(0,0,0) Out[2]: (0, 0, 0, 255) In [3]: pygame.Color(#00) Out[3]: (0, 0, 0, 0) What is the policy regarding backwards compatibility with 1.7.1? Should I put in tests for the old functions as well? Summary: Color construction from string, case insensitivity WebStyle default alpha Module level functions
Re: [pygame] Another blitting surface to itself crash
Thanks Nicholas,
That is kind of interesting, and kind of confusing. Hugo Arts got a
Pygame parachute on XP that was traced to SDL itself. I get a Fatal
Python error, as do you. But unless you use a vintage Windows system as
I do then it would seem the type of error is independent of Windows
version. It behaves as a memory violation, but where. And it is MinGW
specific.
I ran gdb on a small C program that does a self blit. I saw no place
where pointers go astray. The obvious way in which MinGW and VC code
differs is some inline assembly happens with MinGW. But a test on the
inlined assembly code involved with an overlapping blit showed no
problems. I must be making a faulty assumption somewhere.
Lenard
Nicholas Dudfield wrote:
Lenard,
Fatal Python error: Inconsistent interned string state.
On Mon, Aug 18, 2008 at 8:17 AM, Lenard Lindstrom [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yes, debug print statements show the crash happens when the SDL
blit funcion SDL_BlitSurface is called. Did you get a Pygame
parachute or a Python interned string violation?
Lenard
Nicholas Dudfield wrote:
Ok, I have been informed there is are PyGame blits not derived
from SDL, so that explains that.
{pygame_AlphaBlit, pygame_Blit} from clip above looks like
Seems oblivious (sic) now it's pointed out.
On Sat, Aug 16, 2008 at 4:37 PM, Nicholas Dudfield
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
I had a little play with the test_blit_to_self.py:
SDL VERSION:
1.2.13 prebuilts
PYGAME:
Mingw compiled, svn r 1619
OBSERVATIONS:
Unmodified the test wouldn't run at all as noted earlier.
I don't know if it's any help but I noticed after
commenting out
the blitting screen to self section that I could get the
blitting surface to self test and blitting surface to
screen
to run the full 100 cycles if I instantiated the Surface
`a` with
pygame.SRCALPHA flags.
Also, if using BLEND_RGB_ADD flags blitting screen to self
worked. Also screen.copy() worked as a source... but eh.
CONCLUSIONS:
s.blit(s, (0,0)) works if SRCALPHA bits set for s
screen.blit(screen, step, None, pygame.BLEND_RGB_ADD)
Is that any help for you guys in debugging?? I have no C-fu
or I
would have a tinker myself.
--
Lenard Lindstrom
[EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
I've actually gotten both the interned string thing and a pygame parachute
error in the same run
also, I still think the weird _strdup linkage is a good clue. I haven't had
time to try myself, but I think compiling sdl with mingw with source
modified to not call strdup ever will fix the problem.
On Sun, Aug 17, 2008 at 11:55 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote:
Thanks Nicholas,
That is kind of interesting, and kind of confusing. Hugo Arts got a Pygame
parachute on XP that was traced to SDL itself. I get a Fatal Python error,
as do you. But unless you use a vintage Windows system as I do then it would
seem the type of error is independent of Windows version. It behaves as a
memory violation, but where. And it is MinGW specific.
I ran gdb on a small C program that does a self blit. I saw no place where
pointers go astray. The obvious way in which MinGW and VC code differs is
some inline assembly happens with MinGW. But a test on the inlined assembly
code involved with an overlapping blit showed no problems. I must be making
a faulty assumption somewhere.
Lenard
Nicholas Dudfield wrote:
Lenard,
Fatal Python error: Inconsistent interned string state.
On Mon, Aug 18, 2008 at 8:17 AM, Lenard Lindstrom [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] wrote:
Yes, debug print statements show the crash happens when the SDL
blit funcion SDL_BlitSurface is called. Did you get a Pygame
parachute or a Python interned string violation?
Lenard
Nicholas Dudfield wrote:
Ok, I have been informed there is are PyGame blits not derived
from SDL, so that explains that.
{pygame_AlphaBlit, pygame_Blit} from clip above looks like
Seems oblivious (sic) now it's pointed out.
On Sat, Aug 16, 2008 at 4:37 PM, Nicholas Dudfield
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
I had a little play with the test_blit_to_self.py:
SDL VERSION:
1.2.13 prebuilts
PYGAME:
Mingw compiled, svn r 1619
OBSERVATIONS:
Unmodified the test wouldn't run at all as noted earlier.
I don't know if it's any help but I noticed after
commenting out
the blitting screen to self section that I could get the
blitting surface to self test and blitting surface to
screen
to run the full 100 cycles if I instantiated the Surface
`a` with
pygame.SRCALPHA flags.
Also, if using BLEND_RGB_ADD flags blitting screen to self
worked. Also screen.copy() worked as a source... but eh.
CONCLUSIONS:
s.blit(s, (0,0)) works if SRCALPHA bits set for s
screen.blit(screen, step, None, pygame.BLEND_RGB_ADD)
Is that any help for you guys in debugging?? I have no C-fu
or I
would have a tinker myself.
--
Lenard Lindstrom
[EMAIL PROTECTED]
Re: [pygame] Another blitting surface to itself crash
maybe it is memory alignment? Maybe the mmx/sse routines require 8
byte alignment or something?
On Mon, Aug 18, 2008 at 4:55 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote:
Thanks Nicholas,
That is kind of interesting, and kind of confusing. Hugo Arts got a Pygame
parachute on XP that was traced to SDL itself. I get a Fatal Python error,
as do you. But unless you use a vintage Windows system as I do then it would
seem the type of error is independent of Windows version. It behaves as a
memory violation, but where. And it is MinGW specific.
I ran gdb on a small C program that does a self blit. I saw no place where
pointers go astray. The obvious way in which MinGW and VC code differs is
some inline assembly happens with MinGW. But a test on the inlined assembly
code involved with an overlapping blit showed no problems. I must be making
a faulty assumption somewhere.
Lenard
Nicholas Dudfield wrote:
Lenard,
Fatal Python error: Inconsistent interned string state.
On Mon, Aug 18, 2008 at 8:17 AM, Lenard Lindstrom [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yes, debug print statements show the crash happens when the SDL
blit funcion SDL_BlitSurface is called. Did you get a Pygame
parachute or a Python interned string violation?
Lenard
Nicholas Dudfield wrote:
Ok, I have been informed there is are PyGame blits not derived
from SDL, so that explains that.
{pygame_AlphaBlit, pygame_Blit} from clip above looks like
Seems oblivious (sic) now it's pointed out.
On Sat, Aug 16, 2008 at 4:37 PM, Nicholas Dudfield
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
I had a little play with the test_blit_to_self.py:
SDL VERSION:
1.2.13 prebuilts
PYGAME:
Mingw compiled, svn r 1619
OBSERVATIONS:
Unmodified the test wouldn't run at all as noted earlier.
I don't know if it's any help but I noticed after
commenting out
the blitting screen to self section that I could get the
blitting surface to self test and blitting surface to
screen
to run the full 100 cycles if I instantiated the Surface
`a` with
pygame.SRCALPHA flags.
Also, if using BLEND_RGB_ADD flags blitting screen to self
worked. Also screen.copy() worked as a source... but eh.
CONCLUSIONS:
s.blit(s, (0,0)) works if SRCALPHA bits set for s
screen.blit(screen, step, None, pygame.BLEND_RGB_ADD)
Is that any help for you guys in debugging?? I have no C-fu
or I
would have a tinker myself.
--
Lenard Lindstrom
[EMAIL PROTECTED]
Re: [pygame] Physics module status note, more things...
Hey there, Greg! Yep, I did a test implementation of both drag and bouyancy and it looked nice, but had a bad flaw: it didn't take not of contact points. Granted, contact points aren't important when the object is fully submerged, but once on the surface it's needed to calculate displacement and rotational velocity. In my experiment the boxes floating on top of water would be tilted the angle they had when rotation was stopped (due to drag). So, even though my test looked good under water it sucked when floating. I wasn't sure how to overcome this problem so I scrapped it all until someone more capable than me takes a look at it. Here's a few things that might be useful to anybody who has a go with this: 1) Drag is calculated using the fluid viscosity and the surface area exposed in the linear velocity direction, i.e the surface that hits the water head on. Drag is applied in direct opposite to the linear velocity and may be equal to linear velocity (like with viscoisity 1.0, i.e solid), but never more. (just keeping it simple) You might also want to take in account the body friction of the solid, maybe you're making a shaved vs hairy swimmers game? :) 2) Bouyancy is calculated using standard displacement, but for 2D instead of 3D, basically density * area. Density is mass / area. The way I solved this was to be practical. To make things easy I decided that the area would remain if density or mass was changed, just so I, as a game programmer, didn't have to do any density or mass calculations in game code. body.mass = 100 # set density to mass / area, area remains the same body.density = 10 # set mass to density * area, area remains the same body.shape.size = 50,50 # sets mass to density * area, density remains This solved a lot of problems, but I had to add width and height to the shape or reverse the rotational transformation, this needs to be solved nicer. Maybe cache width and height in the shape? This worked great aside from the fact that the whole area was used instead of calculating the submerged area only. This will be vital for correct floating. If someone who is more capable would have go at implementing viscosity support and rudimentary support for netwonian fluid bodies I think it can be done with ease and without disrupting the current implementation of solids too much. I definately think this is the more simple and usable way to do it than adding general dampers to the world or single bodies. I think this would be very useful for making games, maybe the characters will finally float instead of dying when hitting water? :) /Peter On 2008-08-18 (Mon) 13:17, Greg Ewing wrote: Peter Gebauer wrote: In our simple simulation a constant drag force applied in opposite to gravity should be sufficient No, that won't work, because the object will still accelerate indefinitely, or decelerate until it stops completely, whereas it should reach some terminal velocity. we don't have to take in account all the other details of non-solid friction. It doesn't have to be complicated, just a force proportional to the velocity of the object, with a coefficient depending on the fluid and the object concerned. -- Greg
RE: [pygame] Transparency and pygame.draw
No, but someone made bindings for SDL_gfx which does allow for this (and a lot more). Check the list archives. --Noah -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luca Sent: Monday, August 18, 2008 5:28 AM To: pygame-users@seul.org Subject: [pygame] Transparency and pygame.draw Hi all. Is possible to get transparency using primitive pygame.draw functions? For me something like... pygame.draw.ellipse(screen, (0, 127, 0, 140), (300, 150, 80, 40), 0) ... where the color is given with a rgb+alpha value, simply doesn't work. -- -- luca
Re: [pygame] PyGameDB coming along well
a gho is a traditional dress for men in Bhutan. I know this is way OT, but I can't help myself: Do they have gho gho boots? -- brad [bradmontgomery.net]
Re: [pygame] Another blitting surface to itself crash
No mmx/sse instructions are used when source and destination are
identical. Just a string move, rep movsl. I isolated the reverse copy
code in a simple C program. It is attached. There is definitely
something wrong, though I don't know yet. It appears to run just fine
unless I redirect output, then it hangs. Comment out SDL_revcpy and it
runs to completion. So something is being stomped.
Lenard
René Dudfield wrote:
maybe it is memory alignment? Maybe the mmx/sse routines require 8
byte alignment or something?
On Mon, Aug 18, 2008 at 4:55 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote:
Thanks Nicholas,
That is kind of interesting, and kind of confusing. Hugo Arts got a Pygame
parachute on XP that was traced to SDL itself. I get a Fatal Python error,
as do you. But unless you use a vintage Windows system as I do then it would
seem the type of error is independent of Windows version. It behaves as a
memory violation, but where. And it is MinGW specific.
I ran gdb on a small C program that does a self blit. I saw no place where
pointers go astray. The obvious way in which MinGW and VC code differs is
some inline assembly happens with MinGW. But a test on the inlined assembly
code involved with an overlapping blit showed no problems. I must be making
a faulty assumption somewhere.
Lenard
Nicholas Dudfield wrote:
Lenard,
Fatal Python error: Inconsistent interned string state.
On Mon, Aug 18, 2008 at 8:17 AM, Lenard Lindstrom [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yes, debug print statements show the crash happens when the SDL
blit funcion SDL_BlitSurface is called. Did you get a Pygame
parachute or a Python interned string violation?
Lenard
Nicholas Dudfield wrote:
Ok, I have been informed there is are PyGame blits not derived
from SDL, so that explains that.
{pygame_AlphaBlit, pygame_Blit} from clip above looks like
Seems oblivious (sic) now it's pointed out.
On Sat, Aug 16, 2008 at 4:37 PM, Nicholas Dudfield
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
I had a little play with the test_blit_to_self.py:
SDL VERSION:
1.2.13 prebuilts
PYGAME:
Mingw compiled, svn r 1619
OBSERVATIONS:
Unmodified the test wouldn't run at all as noted earlier.
I don't know if it's any help but I noticed after
commenting out
the blitting screen to self section that I could get the
blitting surface to self test and blitting surface to
screen
to run the full 100 cycles if I instantiated the Surface
`a` with
pygame.SRCALPHA flags.
Also, if using BLEND_RGB_ADD flags blitting screen to self
worked. Also screen.copy() worked as a source... but eh.
CONCLUSIONS:
s.blit(s, (0,0)) works if SRCALPHA bits set for s
screen.blit(screen, step, None, pygame.BLEND_RGB_ADD)
Is that any help for you guys in debugging?? I have no C-fu
or I
would have a tinker myself.
#include stdio.h
#include stdlib.h
#define SDL_revcpy(dst, src, len) \
do {\
int u0, u1, u2; \
char *dstp = (char *)(dst); \
char *srcp = (char *)(src); \
int n = (len); \
if ( n = 4 ) { \
__asm__ __volatile__ ( \
std\n\t \
rep ; movsl\n\t \
: =c (u0), =D (u1), =S (u2)\
: 0 (n 2), \
1 (dstp+(n-4)), 2 (srcp+(n-4))\
: memory ); \
} \
switch (n 3) {\
case 3: dstp[2] = srcp[2]; \
case 2: dstp[1] = srcp[1]; \
case 1: dstp[0] = srcp[0]; \
break; \
default:\
break; \
} \
} while(0)
int main(int argc, char *argv[])
{
const int bufsize = 40;
const int padding = 8;
const int blocksize = 20;
char buffer[bufsize+1], *b;
int alignment, dstoffset, i;
buffer[bufsize] = 0; /* null terminated string */
for (alignment = 0; alignment 4; ++alignment)
{
b = buffer + padding + alignment;
for (dstoffset = 0; dstoffset 5; ++dstoffset)
{
for (i = 0; i bufsize; ++i)
{
buffer[i] = '.';
}
for
Re: [pygame] Another blitting surface to itself crash
Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build) On Mon, Aug 18, 2008 at 12:28 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote: No mmx/sse instructions are used when source and destination are identical. Just a string move, rep movsl. I isolated the reverse copy code in a simple C program. It is attached. There is definitely something wrong, though I don't know yet. It appears to run just fine unless I redirect output, then it hangs. Comment out SDL_revcpy and it runs to completion. So something is being stomped. Lenard
Re: [pygame] Another blitting surface to itself crash
I believe I have isolated it to the SDL_revcpy reverse string copy
routine. For gcc is is a macro containing inlined assembly code. For VC
it is a pure C function. It is called when an overlapping copy has a
destination identical to or past the source. Here is demonstration in
Python:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import pygame
s = pygame.Surface((10,10), 0, 32)
s.blit(s, (0, 0), (2, 0, 6, 6))
rect(0, 0, 6, 6)
s.blit(s, (0, 0), (1, 0, 9, 10))
rect(0, 0, 9, 10)
s.blit(s, (0, 0))
Fatal Python error: (pygame parachute) Segmentation Fault
The macro form of SDL_revcpy may inadvertently corrupt a register. It
can only be disabled for gcc by altering a header file.
Lenard
Brian Fisher wrote:
I've actually gotten both the interned string thing and a pygame
parachute error in the same run
also, I still think the weird _strdup linkage is a good clue. I
haven't had time to try myself, but I think compiling sdl with mingw
with source modified to not call strdup ever will fix the problem.
On Sun, Aug 17, 2008 at 11:55 PM, Lenard Lindstrom [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Thanks Nicholas,
That is kind of interesting, and kind of confusing. Hugo Arts got
a Pygame parachute on XP that was traced to SDL itself. I get a
Fatal Python error, as do you. But unless you use a vintage
Windows system as I do then it would seem the type of error is
independent of Windows version. It behaves as a memory violation,
but where. And it is MinGW specific.
I ran gdb on a small C program that does a self blit. I saw no
place where pointers go astray. The obvious way in which MinGW and
VC code differs is some inline assembly happens with MinGW. But a
test on the inlined assembly code involved with an overlapping
blit showed no problems. I must be making a faulty assumption
somewhere.
Lenard
Nicholas Dudfield wrote:
Lenard,
Fatal Python error: Inconsistent interned string state.
On Mon, Aug 18, 2008 at 8:17 AM, Lenard Lindstrom
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Yes, debug print statements show the crash happens when the SDL
blit funcion SDL_BlitSurface is called. Did you get a Pygame
parachute or a Python interned string violation?
Lenard
Nicholas Dudfield wrote:
Ok, I have been informed there is are PyGame blits not
derived
from SDL, so that explains that.
{pygame_AlphaBlit, pygame_Blit} from clip above looks like
Seems oblivious (sic) now it's pointed out.
On Sat, Aug 16, 2008 at 4:37 PM, Nicholas Dudfield
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I had a little play with the test_blit_to_self.py:
SDL VERSION:
1.2.13 prebuilts
PYGAME:
Mingw compiled, svn r 1619
OBSERVATIONS:
Unmodified the test wouldn't run at all as noted
earlier.
I don't know if it's any help but I noticed after
commenting out
the blitting screen to self section that I could
get the
blitting surface to self test and blitting surface to
screen
to run the full 100 cycles if I instantiated the Surface
`a` with
pygame.SRCALPHA flags.
Also, if using BLEND_RGB_ADD flags blitting screen
to self
worked. Also screen.copy() worked as a source... but eh.
CONCLUSIONS:
s.blit(s, (0,0)) works if SRCALPHA bits set for s
screen.blit(screen, step, None, pygame.BLEND_RGB_ADD)
Is that any help for you guys in debugging?? I have
no C-fu
or I
would have a tinker myself.
--
Lenard Lindstrom
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
--
Lenard Lindstrom
[EMAIL PROTECTED]
[pygame] Lepton particle engine 0.6a released
(I didn't see this come through, so I'm sending it from my other address, apologies if it's a dupe) I'm pleased to announce the 0.6 alpha release of Lepton, a high-performance, pluggable particle engine and API for Python. Although it is still under development, a critical mass of features are completed and I think it is ready for wider consumption. Note that this is an alpha release, so expect the API to change somewhat in future releases. New features are also under development. The engine is designed to be very flexible and does not rely on any other libraries directly. You can use it either with OpenGL (via pyglet or PyOpenGL), or with pygame by selecting the appropriate renderer. Examples are provided using pyglet and pygame. The project page is here: http://code.google.com/p/py-lepton/ You can also get it via pypi here: http://pypi.python.org/pypi/lepton/ One of the missing pieces right now is a native binary installer for Windows. It can be compiled using cygwin or MinGW, but we could use some help getting it working with MSVC. If anyone would like to contribute their Visual Studio expertise, it would be greatly appreciated. If you have questions or comments or would like to contribute, you can join our google group at: http://groups.google.com/group/py-lepton-users Enjoy. -Casey
Re: [pygame] Another blitting surface to itself crash
I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build) On Mon, Aug 18, 2008 at 12:28 PM, Lenard Lindstrom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: No mmx/sse instructions are used when source and destination are identical. Just a string move, rep movsl. I isolated the reverse copy code in a simple C program. It is attached. There is definitely something wrong, though I don't know yet. It appears to run just fine unless I redirect output, then it hangs. Comment out SDL_revcpy and it runs to completion. So something is being stomped. Lenard -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Transparency and pygame.draw
Will SDL_gfx ever be actually included in pygame? On Mon, Aug 18, 2008 at 11:38 AM, Noah Kantrowitz [EMAIL PROTECTED]wrote: No, but someone made bindings for SDL_gfx which does allow for this (and a lot more). Check the list archives. --Noah -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luca Sent: Monday, August 18, 2008 5:28 AM To: pygame-users@seul.org Subject: [pygame] Transparency and pygame.draw Hi all. Is possible to get transparency using primitive pygame.draw functions? For me something like... pygame.draw.ellipse(screen, (0, 127, 0, 140), (300, 150, 80, 40), 0) ... where the color is given with a rgb+alpha value, simply doesn't work. -- -- luca -- - pymike (http://pymike.4rensics.org/)
Re: [pygame] Transparency and pygame.draw
Maybe... I find this with google (but I don't find the patch Noah was talink about...) http://www.pygame.org/wiki/gsoc2008ideas#Better%20drawing%20primitives On Mon, Aug 18, 2008 at 11:43 PM, PyMike [EMAIL PROTECTED] wrote: Will SDL_gfx ever be actually included in pygame? On Mon, Aug 18, 2008 at 11:38 AM, Noah Kantrowitz [EMAIL PROTECTED] wrote: No, but someone made bindings for SDL_gfx which does allow for this (and a lot more). Check the list archives. --Noah -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luca Sent: Monday, August 18, 2008 5:28 AM To: pygame-users@seul.org Subject: [pygame] Transparency and pygame.draw Hi all. Is possible to get transparency using primitive pygame.draw functions? For me something like... pygame.draw.ellipse(screen, (0, 127, 0, 140), (300, 150, 80, 40), 0) ... where the color is given with a rgb+alpha value, simply doesn't work. -- -- luca -- - pymike (http://pymike.4rensics.org/) -- -- luca
Re: [pygame] Another blitting surface to itself crash
That seems to be it. Try out the modified SDL.dll for Pythons 2.4. and 2.5: http://www3.telus.net/len_l/pygame/SDL-self-blit.zip md5sum: 59a283f9383d6b5512c236d98e39c97b *SDL-self-blit.zip Lenard Lenard Lindstrom wrote: I will. But it will be hand-customized. Lenard Brian Fisher wrote: Hey Lenard, Can you build SDL with mingw in a way that the inlined assembly won't be used? (i.e. so that it uses the same source that VisualC does to build)
Re: [pygame] PyGameDB coming along well
Brad Montgomery wrote: I know this is way OT, but I can't help myself: Do they have gho gho boots? Apparently it's just a robe, sometimes with a scarf, so I don't think boots are part of the specification. There's a wikipedia article here: http://en.wikipedia.org/wiki/Gho -- Greg
Re: [pygame] PyGameDB coming along well
GhoGame? OxyGho? GhoGho? I think we need to vote on something :) On Tue, Aug 19, 2008 at 1:55 AM, Greg Ewing [EMAIL PROTECTED] wrote: Brad Montgomery wrote: I know this is way OT, but I can't help myself: Do they have gho gho boots? Apparently it's just a robe, sometimes with a scarf, so I don't think boots are part of the specification. There's a wikipedia article here: http://en.wikipedia.org/wiki/Gho -- Greg -- Thanks, Richie Ward
Re: [pygame] PyGameDB coming along well
GhoUL! (Gho UnLimited?) On Mon, Aug 18, 2008 at 9:40 PM, Richie Ward [EMAIL PROTECTED] wrote: GhoGame? OxyGho? GhoGho? I think we need to vote on something :) On Tue, Aug 19, 2008 at 1:55 AM, Greg Ewing [EMAIL PROTECTED] wrote: Brad Montgomery wrote: I know this is way OT, but I can't help myself: Do they have gho gho boots? Apparently it's just a robe, sometimes with a scarf, so I don't think boots are part of the specification. There's a wikipedia article here: http://en.wikipedia.org/wiki/Gho -- Greg -- Thanks, Richie Ward -- - pymike (http://pymike.4rensics.org/)
