Re: [pygame] FW: BOUNCE: RenderPlain and new method in Sprite

[Pete Shinners <shredwheat@attbi.com>]

> But what if I want to change the drawing behaviour depending on what sprite
> I'm drawing. Perhaps some sprites should be combined with
> mask/blend/whatever. The best way is that each sprite must implement their
> own draw. The simplest form of draw() method should be in the Sprite class,
> a simple blit (like the one in RenderPlain) should be enough.
> 
> So RenderPlain (and any other Group that wants to call draw() on a Sprite)
> should itterate the sprite dictionary, but instead of actualy doing 
> anything
> it should call the sprites draw() method, just like is done with update().

yeah, the current Sprite classes cover the general and fast cases.
recently this came up with some other users, and i showed some examples
of extending the RenderUpdates class to support drawing 2 images per
sprite, and another class that called Sprite.draw() to draw each sprite.

that post is here,
http://archives.seul.org/pygame/users/Mar-2002/msg00007.html

it would be sort of nice if the render groups could be really flexible 
and handle a lot of cases, my main concern was that there would be a 
noticeable speed hit, i think it's best if you just use or create a 
render group that does what you want.

you can also have multiple render groups for your scene, this can make 
it easy to draw different sprites in different ways. in fact if you need 
specific layering, the way to do it is with multiple render groups.
(i'm thinking i'll add this sort of info to the current sprite tutorial)

actually, i've never really benchmarked the difference in calling 
Sprite.draw() instead of calling screen.blit(Sprite.image). i've a 
feeling it will definitely show up on the fps-o-meter. but if 
performance is comparable then i would like to make the render groups 
more flexible like this.

i've already taken one small step towards this, now the render groups 
clear() method can accept a background drawing function, instead of just 
an image.

lately i've also been curious about moving some of the sprite functions 
into c code, to see what can be done in that arena.


____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org