Hey all!
I wondered if the these two issues will be addressed?
1) The fact that heavy mass objects fall through static objects with low
mass. Static objects should probably be treated like inf mass.
(it's as if they first hit water and then slowly sink through)
2) Locked joint rotation. There
It's a bit confusing at first, until you realize what fill is: It's a
way to set large numbers of pixels to the same value, completely
ignoring whatever was there before. Since this is a write-only,
no-decision operation, it's very fast. The flags are just extra
attributes that you're setting,
Actually, come to think of it, it might be a good idea to add a
function that has the expected effect. Essentially the optimized C
equivalent of:
def naive_fill(self, color, rect, flags):
blit_me = pygame.Surface(rect[2:])
blit_me.fill(color, None, flags)
self.blit(blit_me, rect)
Hi Peter,
Yes, the problems exist in this engine. It needs future works. Now, Google
suggests us the students pencil-down after August 18th and make final
evaluation on these gsoc projects. So, during this time, I didn't add any codes
and functions. The version of this physics engine
Thats great, I normally work with open source design tools but I can
get hold of photoshop.
On Fri, Aug 29, 2008 at 5:43 AM, Devon Scott-Tunkin
[EMAIL PROTECTED] wrote:
I played around with your template a little bit, adding some web 2.0ness and
whatnot and adding some orange to make it less
Thanks Brian, it's good to know why it was doing that, and even better to
already have it fixed.
Charlie, the blend fill option is new in 1.8.0. As you said, normally I
wouldn't expect the fill to be anything but a dumb *splort* all over what was
already there, but the new Surface.fill docs
Charlie Nolan wrote:
def naive_fill(self, color, rect, flags):
blit_me = pygame.Surface(rect[2:])
blit_me.fill(color, None, flags)
self.blit(blit_me, rect)
Seems to me this is what draw.rect *should* be equivalent
to. Is that the case these days?
--
Greg
rect doesn't support the flags. Because it was brought over from some old
version of SFL_gfx, and people haven't been exactly sure what to do with it,
it hasn't really developed the way other stuff has.
On Sat, Aug 30, 2008 at 6:15 PM, Greg Ewing [EMAIL PROTECTED]wrote:
Charlie Nolan wrote:
