Re: [pygame] Physics module status note, more things...
Hi, Nice idea and suggestion! Thank you. First, "3. Algorithm For particle simulation *DONE***" in TODOLIST is a step in todolist of previous coding phase. particle simulation is very simple and implemented at beginning(not need to consider shape and constraint). Second, in fact, air friction has already been added by a simple damping algorithm (body.linear_vel_damping and body.angle_vel_damping). I also add a new test case (test5.py), it's a chain simulation with damping of velocity enabled. you can compare it with test4.py. :-) Best wishes Zhang Fan Peter Gebauer <[EMAIL PROTECTED]> 写道： Sweet! I have a new question as well. :) >From the todo: 3. Algorithm For particle simulation *DONE*** What is it? Bodies with a single point shape? I've already done a dozen experiments with the latest svn updates, everything looks excellent so far. I'm really impressed with Zhang Fan's effort. Your assistance is also appreciated. Good work guys! I see in the quote the issue of falling through other bodies, it is relevant to the "fluid" discussion as well. It would probably prove valuable to have friction in "air" as well simply to get a terminal velocity. I'm working on a fluid solution that would intergate nicely with solids, this still involves changing the behavior of a collision between two bodies. >From what I've gathered, implementing a rudementary dynamic viscosity for netwonian fluids based on friction (or a separate attribute for viscosity where 0.0 is vacuum and 1.0 is a solid) wouldn't be that hard. /Peter On 2008-08-15 (Fri) 15:33, [EMAIL PROTECTED] wrote: > Peter Gebauer : > >> Hi again! >> >> Should have waited with my previous post, but here's a few things I don't >> understand: >> >> 1) if the mass of a static body is under 1.0 it behaves as a semi-solid, >> is this intentional? (i.e other bodies fall "into" the static body and with >> mass reaching 0.0 they fall right through) >> In test3.py, set the static body mass to 0.1, as an example. > > This is due to the fact, that the current collision algorithm is not a CCD > method. Thus the collision detection highly depends on the step time, size > and speed of a body. Other systems, which do not implement a CCD, suffer from > the same issue. Zhang Fan wrote a lot about that in pgShapeObject.c. > > In order to get rid of that, you have to choose matching step times, sizes > and the speed for bodies according to your simulation needs - at least as > long as there is no CCD algorithm implemented :-). > >> 2) is there a way to get simulated bouncing? If there was a way to describe >> how much energy the object retains (in new direction) after collision, a >> float between 0.0 and 1.0 (0-100% energy retained, 0.01 would be a rock and >> 0.5 would be more of a tennis ball)? > > Simulated bouncing is implemented already. The collision energy, and how it > is applied on the colliding bodies, depends on the restitution set for them. > So, whether you will receive an elastic or inelastic collision, depends on > that factor. A quick search for "Coefficient of restitution" and > "elastic collisions" will provide you tons of explanations and even some > values for different materials. > Attached you'll find a small bouncing test script. > >> 3) can we add bouyancy? :) Body 1 is called "floater" and Body 2 is called >> "water", if floater is inside water it should, depending on it' >> displacement, either pop back up or sink to the bottom. We would >> be able to calculate this with the already existing shape, mass and friction >> attributes, but it would probably require a new boolean attribute, maybe >> "solid"? > > Here's how I'd do it. > > * create a World with relatively high damping, the gravity vector points to > the top (e.g. world.gravity = 0, -3). > * place body into that world with a certain damping, mass, etc. > * have fun watching the simulation. > > Limiting the world's area would be left to the user. As you can have multiple > worlds, which behave completely different, you could e.g. split the screen > into "sky" and "sea", being two different worlds. If the body reaches a > certain point, you could remove it from "sea" and add it to "sky" > (which reminds of adding remove_* methods, so wait 'til the end of the > weekend before doing that ;-). > > Simulating a varying density of the world would require a slightly > different approach for worlds. Currently the world does not know anything > about its size and such, that however would be necessary, I think. > > Regards > Marcus > > > # The python file is under test > > import pygame > import physics > from pygame.locals import * > > def render_body(body,surface,color): > l = body.get_points() > pygame.draw.polygon(surface,color,l) > > def render_world(world,surface,color): > for body in world.bodies: > render_body(body,surface,color) > > > def init_world(): > w = physics.World() > w.gravity = 0, 2 > > body1 = physics.Body() > body1.shape
Re: [pygame] PyGameDB coming along well
I would suggexst monoxide, but that kind of makes it sound like it uses mono. How about snake oil? That's pretty catchy.
Re: [pygame] PyGameDB coming along well
On Sun, Aug 17, 2008 at 02:04:00PM +1000, Richard Jones wrote: > On Sun, 17 Aug 2008, Brad Montgomery wrote: > > >> Or possibly a pun on Steam ;) > > > > > > Gaseous Dihydrogen Monoxide! > > > > GaDiMo? > > Hell, just GDM :) > > Then if asked we can say it's either Game Database Manager or Gaseous > Dihydrogen Monoxide (or Giant Deadly Manatees) > Unfortunately GDM also stands for "Gnome Display Manager", so the name would conflict with a pre-installed package on an extremely large slice of Linux systems. Or, I dunno. Maybe a lawsuit from the Gibraltar Democratic Movement... --- James Paige
Re: [pygame] PyGameDB coming along well
On Sun, 17 Aug 2008, Brad Montgomery wrote: > >> Or possibly a pun on Steam ;) > > > > Gaseous Dihydrogen Monoxide! > > GaDiMo? Hell, just GDM :) Then if asked we can say it's either Game Database Manager or Gaseous Dihydrogen Monoxide (or Giant Deadly Manatees) Richard
Re: [pygame] PyGameDB coming along well
On Sat, Aug 16, 2008 at 09:27:39PM -0500, Brad Montgomery wrote: > > >>Or possibly a pun on Steam ;) > > > >Gaseous Dihydrogen Monoxide! > > GaDiMo? > > Isn't that the name of an album by "Juno Reactor"? --- James Paige
Re: [pygame] PyGameDB coming along well
Sounds Japanese.
Re: [pygame] PyGameDB coming along well
Or possibly a pun on Steam ;) Gaseous Dihydrogen Monoxide! GaDiMo?
Re: [pygame] PyGameDB coming along well
Richard Jones wrote: Yeah, to be hip and current it needs to be a single, possibly made-up word :) Or possibly a pun on Steam ;) Gaseous Dihydrogen Monoxide! -- Greg
Re: [pygame] Physics module status note, more things...
Peter Gebauer wrote: Great point, I was thinking about using the friction attribute to achieve this, but maybe something like viscosity is better to calculate drag? A separate parameter would probably be better, since unlike friction between solid surfaces, the drag force has to be velocity-dependent -- otherwise the object would slow down and stop somewhere in the fluid instead of reaching a terminal velocity. -- Greg
Re: [pygame] PyGameDB coming along well
On Sat, 16 Aug 2008, Dan Krol wrote: > This is fantastic, I didn't know this was in the works. I, too, was unaware of it. Somehow I missed the original announcement. I'd love to see this capable of playing games from pyweek :) I'd be very happy to talk about how to adapt the pyweek Skellington to be more useful. Also for there to be a useful API on pyweek.org for it. Richard
Re: [pygame] PyGameDB coming along well
On Sun, 17 Aug 2008, Frozenball wrote: > Quick mockups (svg): > > http://img105.imageshack.us/img105/6708/pygamedbqs5.png > http://img178.imageshack.us/img178/7016/pygamedblogocirclela2.png > http://img178.imageshack.us/img178/7889/pygamedb3db4.png > > Personally I think that the name (PygameDB) is too long and technical > for new users. Yeah, to be hip and current it needs to be a single, possibly made-up word :) Or possibly a pun on Steam ;) Richard
Re: [pygame] PyGameDB coming along well
Richie Ward wrote: The PyGameDB project which has similarity's to the commercial platform "Steam" is coming to a usable state. [snip] A huge feature is that it will make it easy to deploy pygame's since you do not need to package them as a .exe. This is good. I predict py2exe breaks big time for Python 2.6/3.0. No Python 2.6 py2exe installer yet on SourceForge, though it is in works. -- Lenard Lindstrom <[EMAIL PROTECTED]>
Re: [pygame] Physics module status note, more things...
Note that, to simulate water, you can't just set the world's gravity negative: The rate a submerged object accelerates upwards depends on the mass of the object. Consider two boxes of the same size, one with a vacuum and another full of Styrofoam. Both float and both displace the same amount of water, (and therefore get the same upthrust). However, the one with the vacuum weighs less, and so the gravitational force on it is less. This means that the resultant vector (pointing up) of the Styrofoam box is *smaller* than that of the vacuum box. With a force on the vacuum box greater than that on the Styrofoam box, the vacuum box should accelerate faster because Force and Acceleration are directly proportional (F=M*A). But wait! Look at the M! The vacuum box weighs far less than the Styrofoam block *and* it masses less. Thus, the vacuum box's acceleration is even faster. Obviously a bit more complicated than anti-gravity... Ian
Re: [pygame] blit anomalies in pygame 1.8.1release (2)
Hi Nicholas, Nicholas Dudfield wrote: Lenard, Rene and co, >> There is no unit test for blitting a SRCALPHA source with non-zero alpha to a SRCALPHA destination with non-zero alpha I'm writing some tests for surface.blit atm. What is the expected behaviour of such an operation? def test_blit__SRCALPHA_to_SRCALPHA_non_zero(self): # " There is no unit test for blitting a SRCALPHA source with non-zero # alpha to a SRCALPHA destination with non-zero alpha " LL w,h = size = 32,32 s = pygame.Surface(size, pygame.SRCALPHA, 32) s2 = s.copy() s.fill((32,32,32,111)) s2.fill((32,32,32,31)) s.blit(s2, (0,0)) # TODO: # what is the correct behaviour ?? should it blend? what algorithm? self.assertEquals(s.get_at((0,0)), (32,32,32,31)) Cheers. I'm not sure here. I get (32, 32, 32, 129). Here is a floating point equation for alpha blend of an rgb color element in a pixel. It is adapted from the one in the Python Image Library (PIL): (dst * (255.0 - alpha) + src * alpha) / 255.0 So when src = dst = c: (c * (255.0 - alpha) + c * alpha) / 255.0 = (c * 255.0 - c * alpha + c * alpha) = c If source and destination colors are the same the resulting color is also the same, irregardless of alpha. Pygame calculates the new alpha value with some averaging formula I don't recognize: dA = sA + dA - ((sA * dA) / 255) So sA = 31 and dA = 111 gives 129. Also, wrt to the blitting opaque source behaviour, are we considering this a bug? A failed test? I'm that way inclined and have written a test for that, will wait for approval before committing. def test_blit__SRCALPHA_opaque_source(self): src = pygame.Surface( (256,256), SRCALPHA ,32) dst = src.copy() for i, j in test_utils.rect_area_pts(src.get_rect()): dst.set_at( (i,j), (i,0,0,j) ) src.set_at( (i,j), (0,i,0,255) ) dst.blit(src, (0,0)) for pt in test_utils.rect_area_pts(src.get_rect()): self.assertEquals ( dst.get_at(pt)[1], src.get_at(pt)[1] ) According to the above floating point blend equation and Pygame's alpha equation this unit test should hold true. I have made it so in SVN. But will the change stick this time? Maybe there are some other instances where the new blend equation gives a slightly different value to the replaced equation. But will this truly cause breakage? -- Lenard Lindstrom <[EMAIL PROTECTED]>
Re: [pygame] Physics module status note
glRotatef(90,0,1,0) 90 degrees around y-axis. ;-) Ian
Re: [pygame] PyGameDB coming along well
Opps. Last one rather.
Re: [pygame] PyGameDB coming along well
Like the first one best.
[pygame] Pygame 1.8.x on latest kubuntu/ubuntu
Hi all. Anyone is trying to use pygame 1.8 version from the debian/apt on ubuntu/kubuntu? The download page of pygame.org say that ubuntu support 1.8. I've already all universe repository in my sources.list, but my local version on pygame is still the 1.7.1. Thanks! -- -- luca
Re: [pygame] PyGameDB coming along well
Quick mockups (svg): http://img105.imageshack.us/img105/6708/pygamedbqs5.png http://img178.imageshack.us/img178/7016/pygamedblogocirclela2.png http://img178.imageshack.us/img178/7889/pygamedb3db4.png Personally I think that the name (PygameDB) is too long and technical for new users. On Sat, Aug 16, 2008 at 6:25 PM, Frozenball <[EMAIL PROTECTED]> wrote: > I woud love to help you with the logo and website. > > P.S. Are there any legal issues (trademarks etc.) to use the word > 'pygame' in the title? >
Re: [pygame] Physics module status note
ah, I was under the impression that the OpenGL API also used radians. In that case I can't object any further. On Sat, Aug 16, 2008 at 6:39 AM, Marcus von Appen <[EMAIL PROTECTED]> wrote: > On, Sat Aug 16, 2008, Peter Gebauer wrote: > >> Hi there, Hugo! >> >> Yes, using radians in math-related softare is common, but not in games. >> It will simply add a call the math.degrees for every call and to increment >> the angle you'd have to convert it back, or be forced to use radians >> in the game. If you're drawing using OpenGL or any rotational >> transformations it will be a lot of calls. I see it as more comfortable when >> the angles use degrees since graphic drawing is more common than in a game >> than asin/atan calls. >> It will also be a miniscule performance enhancenment to do this in C >> rather than Python which will add up if you do this conversion many times >> for each polygon you draw. :) >> >> So, it's more comfortable to use degrees and it's better suited for use with >> graphic libraries, which mostly use degrees, including >> pygame.transform.rotate. > > [...] > > Seconded. As doing a degrees to radians "just" adds a float > multiplication and division, it should not be a big deal. I'll add that > to the TODO list. > > Regards > Marcus >
Re: [pygame] PyGameDB coming along well
I woud love to help you with the logo and website. P.S. Are there any legal issues (trademarks etc.) to use the word 'pygame' in the title? On Fri, Aug 15, 2008 at 8:25 PM, Richie Ward <[EMAIL PROTECTED]> wrote: > The PyGameDB project which has similarity's to the commercial platform > "Steam" is coming to a usable state. > > It is programmed in Python + WxPython. > It works by adding the game to sys.path and importing the game (very > simplified way to put it). > It uses a XML file to get a list of PyGame's. It will also work with > other types of python games, including opengl based ones, as long as > they are open source. > A huge feature is that it will make it easy to deploy pygame's since > you do not need to package them as a .exe. > It allows anyone to make a game repository, the XML file url can be > set inside the application! > > I am currently looking for help with: > * The pygamedb-server which is a website programmed in cherrypy or > pylons which will allow people to submit/upload games and generates > the resulting xml file. > * Beta testers for the client and someone that can test it on Mac OSX > * Someone to make me a pygamedb logo, I am useless with graphics! > * Someone with knowlege of WxPython thats willing to help with the client gui. > > The project is currently missing a big feature, dependency/library > support (It ignores that in the xml file right now). That will be > finished very soon. > > You can see a screenshot here: http://richies.googlepages.com/Screenshot-1.png > The test repo is hosted here: http://pygamedb.4rensics.org/ > The test XML Data file is here: http://pygamedb.4rensics.org/pygamedb.xml > > I plan to get a domain name once pygamedb-server is done.. pygamedb.org maybe? > > Getting it > === > The project lives at: https://launchpad.net/pygamedb > > Windows > http://launchpad.net/bzr/1.6/1.6beta3/+download/bzr-setup-1.6b3.exe > http://downloads.sourceforge.net/wxpython/wxPython2.8-win32-unicode-2.8.8.1-py25.exe > http://sourceforge.net/project/showfiles.php?group_id=78018 > Install all of the above. > > Debian/Ubuntu > python-wxgtk2.8, bzr > > Once you installed that, Run this command: > bzr branch lp:pygamedb > > Running it > === > Windows > rename pygamedb to pygamedb.py and then run it. > > On all other os's just run pygamedb > > -- > Thanks, Richie Ward >
Re: [pygame] Physics module status note, more things...
Sweet! I have a new question as well. :) >From the todo: 3. Algorithm For particle simulation *DONE*** What is it? Bodies with a single point shape? I've already done a dozen experiments with the latest svn updates, everything looks excellent so far. I'm really impressed with Zhang Fan's effort. Your assistance is also appreciated. Good work guys! I see in the quote the issue of falling through other bodies, it is relevant to the "fluid" discussion as well. It would probably prove valuable to have friction in "air" as well simply to get a terminal velocity. I'm working on a fluid solution that would intergate nicely with solids, this still involves changing the behavior of a collision between two bodies. >From what I've gathered, implementing a rudementary dynamic viscosity for netwonian fluids based on friction (or a separate attribute for viscosity where 0.0 is vacuum and 1.0 is a solid) wouldn't be that hard. /Peter On 2008-08-15 (Fri) 15:33, [EMAIL PROTECTED] wrote: > Peter Gebauer <[EMAIL PROTECTED]>: > >> Hi again! >> >> Should have waited with my previous post, but here's a few things I don't >> understand: >> >> 1) if the mass of a static body is under 1.0 it behaves as a semi-solid, >> is this intentional? (i.e other bodies fall "into" the static body and with >> mass reaching 0.0 they fall right through) >> In test3.py, set the static body mass to 0.1, as an example. > > This is due to the fact, that the current collision algorithm is not a CCD > method. Thus the collision detection highly depends on the step time, size > and speed of a body. Other systems, which do not implement a CCD, suffer from > the same issue. Zhang Fan wrote a lot about that in pgShapeObject.c. > > In order to get rid of that, you have to choose matching step times, sizes > and the speed for bodies according to your simulation needs - at least as > long as there is no CCD algorithm implemented :-). > >> 2) is there a way to get simulated bouncing? If there was a way to describe >> how much energy the object retains (in new direction) after collision, a >> float between 0.0 and 1.0 (0-100% energy retained, 0.01 would be a rock and >> 0.5 would be more of a tennis ball)? > > Simulated bouncing is implemented already. The collision energy, and how it > is applied on the colliding bodies, depends on the restitution set for them. > So, whether you will receive an elastic or inelastic collision, depends on > that factor. A quick search for "Coefficient of restitution" and > "elastic collisions" will provide you tons of explanations and even some > values for different materials. > Attached you'll find a small bouncing test script. > >> 3) can we add bouyancy? :) Body 1 is called "floater" and Body 2 is called >> "water", if floater is inside water it should, depending on it' >> displacement, either pop back up or sink to the bottom. We would >> be able to calculate this with the already existing shape, mass and friction >> attributes, but it would probably require a new boolean attribute, maybe >> "solid"? > > Here's how I'd do it. > > * create a World with relatively high damping, the gravity vector points to > the top (e.g. world.gravity = 0, -3). > * place body into that world with a certain damping, mass, etc. > * have fun watching the simulation. > > Limiting the world's area would be left to the user. As you can have multiple > worlds, which behave completely different, you could e.g. split the screen > into "sky" and "sea", being two different worlds. If the body reaches a > certain point, you could remove it from "sea" and add it to "sky" > (which reminds of adding remove_* methods, so wait 'til the end of the > weekend before doing that ;-). > > Simulating a varying density of the world would require a slightly > different approach for worlds. Currently the world does not know anything > about its size and such, that however would be necessary, I think. > > Regards > Marcus > > > # The python file is under test > > import pygame > import physics > from pygame.locals import * > > def render_body(body,surface,color): > l = body.get_points() > pygame.draw.polygon(surface,color,l) > > def render_world(world,surface,color): > for body in world.bodies: > render_body(body,surface,color) > > > def init_world(): > w = physics.World() > w.gravity = 0, 2 > > body1 = physics.Body() > body1.shape = physics.RectShape(30, 28, 0) > body1.position = 400, 40 > body1.rotation = i > body1.restitution = 0.9 > body1.mass = 20 > w.add_body(body1) > > body2 = physics.Body() > body2.shape = physics.RectShape (760, 20, 0) > body2.position = 400, 600 > body2.restitution = 1.0 > body2.mass = 1e100 > body2.static = True > w.add_body(body2) > return w > > > def main(): > """this function is called when the program starts. >it initializes everything it needs, then runs in >a loop until the fun
Re: [pygame] Physics module status note
On, Sat Aug 16, 2008, Peter Gebauer wrote: > Hi there, Hugo! > > Yes, using radians in math-related softare is common, but not in games. > It will simply add a call the math.degrees for every call and to increment > the angle you'd have to convert it back, or be forced to use radians > in the game. If you're drawing using OpenGL or any rotational > transformations it will be a lot of calls. I see it as more comfortable when > the angles use degrees since graphic drawing is more common than in a game > than asin/atan calls. > It will also be a miniscule performance enhancenment to do this in C > rather than Python which will add up if you do this conversion many times > for each polygon you draw. :) > > So, it's more comfortable to use degrees and it's better suited for use with > graphic libraries, which mostly use degrees, including > pygame.transform.rotate. [...] Seconded. As doing a degrees to radians "just" adds a float multiplication and division, it should not be a big deal. I'll add that to the TODO list. Regards Marcus pgp9iIUzV4wcV.pgp Description: PGP signature
Re: [pygame] Physics module status note, more things...
Hey Greg! Man, everybody in this list are so responsive, I like it. > You'll also want a drag force proportional to the velocity > of the body and the immersed volume, to stop it from > accelerating indefinitely while submerged, and to damp > down oscillations when it's floating on the surface. Great point, I was thinking about using the friction attribute to achieve this, but maybe something like viscosity is better to calculate drag? Or is viscosity based on friction? Gotta Wikipedia this. If we could add this attribute (calling it viscosity, just for the sake of argument) to both worlds and bodies you can get terminal velocity for air, water and whatever non-solids you might like to simulate. It would also make sure that projectiles slow down faster in "water". If you want a fancy version you could include surface area in the drag calculation. /Peter
Re: [pygame] Physics module status note
Hi there, Hugo! Yes, using radians in math-related softare is common, but not in games. It will simply add a call the math.degrees for every call and to increment the angle you'd have to convert it back, or be forced to use radians in the game. If you're drawing using OpenGL or any rotational transformations it will be a lot of calls. I see it as more comfortable when the angles use degrees since graphic drawing is more common than in a game than asin/atan calls. It will also be a miniscule performance enhancenment to do this in C rather than Python which will add up if you do this conversion many times for each polygon you draw. :) So, it's more comfortable to use degrees and it's better suited for use with graphic libraries, which mostly use degrees, including pygame.transform.rotate. /Peter On 2008-08-15 (Fri) 15:39, Hugo Arts wrote: > most of python's math functions like asin en atan (from math) return > their values in radians, and sin and tan take their arguments as > radians. So using radians is more common than degrees. > Conversion is also pretty trivial, using math.radians and math.degrees. > > Hugo > > On Fri, Aug 15, 2008 at 6:53 AM, Peter Gebauer > <[EMAIL PROTECTED]> wrote: > > Hi! > > > > Hm, I've been experimenting a bit now and I wonder about the > > body.rotation, it's using radians. Wouldn't it make more sense to use > > degrees in the API for all angle values? > > > > On 2008-08-14 (Thu) 21:35, Marcus von Appen wrote: > >> On, Thu Aug 14, 2008, Peter Gebauer wrote: > >> > >> [...] > >> > Too early for a wishlist? :) > >> > >> No, but do not expect it to be implemented within the next days > >> ;-). We'd be happy to discuss and put your wishes on the TODO list. > >> > >> Regards > >> Marcus > > > > > > >
Re: [pygame] Physics module status note, more things...
Hi, Currently, there're only a simple distance joint yet, it can only limit the attached bodies' rotation by solving distance constraint. Locking rotation may be added in other joints in future. Peter Gebauer <[EMAIL PROTECTED]> Nice reply Marcus! > In order to get rid of that, you have to choose matching step times, sizes > and the speed for bodies according to your simulation needs - at least as > long as there is no CCD algorithm implemented :-). One final question: is it possible to lock joint rotation (no rotation)? /Peter - 雅虎邮箱，您的终生邮箱！
Re: [pygame] Physics module status note, more things...
Hi, Currently, Friction is not added yet, of course, it must be done later. Peter Gebauer <[EMAIL PROTECTED]> 写道： Oh dear, I'm spamming the channel. 4) Friction does nothing yet? Can't find it being used except to hold a value and changing it makes no difference. On 2008-08-15 (Fri) 14:14, Peter Gebauer wrote: > Hi again! > > Should have waited with my previous post, but here's a few things I don't > understand: > > 1) if the mass of a static body is under 1.0 it behaves as a semi-solid, > is this intentional? (i.e other bodies fall "into" the static body and with > mass reaching 0.0 they fall right through) > In test3.py, set the static body mass to 0.1, as an example. > > This isn't really useful for making fluids either since there doesn't seem > to be an bouyancy to the falling bodies, i.e they don't pop back up again. > > 2) is there a way to get simulated bouncing? If there was a way to describe > how much energy the object retains (in new direction) after collision, a > float between 0.0 and 1.0 (0-100% energy retained, 0.01 would be a rock and > 0.5 would be more of a tennis ball)? > > 3) can we add bouyancy? :) Body 1 is called "floater" and Body 2 is called > "water", if floater is inside water it should, depending on it' > displacement, either pop back up or sink to the bottom. We would > be able to calculate this with the already existing shape, mass and friction > attributes, but it would probably require a new boolean attribute, maybe > "solid"? > > Hm. I'm sure I'll be able to think of something else later. :) > > /Peter > - 雅虎邮箱，您的终生邮箱！
Re: [pygame] Another blitting surface to itself crash
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]>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.
>
> Cheers.
>
> ps... attached modified version of test with "use alpha blit" changes
>
>
> pps.
>
> This is in surface.c around line 1996 ??
>
> /* see if we should handle alpha ourselves */
> if (dst->format->Amask && (dst->flags & SDL_SRCALPHA) &&
> !(src->format->Amask && !(src->flags & SDL_SRCALPHA)) &&
> /* special case, SDL works */
> (dst->format->BytesPerPixel == 2 || dst->format->BytesPerPixel ==
> 4))
> {
> result = pygame_AlphaBlit (src, srcrect, dst, dstrect, the_args);
> }
> else if (the_args != 0)
> {
> result = pygame_Blit (src, srcrect, dst, dstrect, the_args);
> }
> else
> {
> result = SDL_BlitSurface (src, srcrect, dst, dstrect);
> }
>
>
>
