Re: [pygame] Could sprite drawing be done but a Sprite.draw function?

[Mac Ryan <quasipedia@xxxxxxxxx>]

On Mon, 25 Jul 2011 06:45:44 +0100
Renà Dudfield <renesd@xxxxxxxxx> wrote:

> There are things like z-order as well, which make drawing in the
> group the way to do it.  If you did Sprite drawing, then each Sprite
> would first need to talk to the other sprites in order to know when
> to draw.

Hi and thank you for your answer.

	I think I failed to explain myself properly. What I meant with
my question is that I have been surprised that the drawing of sprites
happens **calling surface.blit(sprite.image, sprite.rect)** instead than
**calling sprite.draw()**. It makes of course sense that drawing is
co-ordinated by the group, but the way it's done now make very hard to
"customise" the drawing: I might need for example to selectively choose
a flag for the blit operation on _some_ of the sprites, for example...

	Hope this clarify what's my doubt better! :)

	Mac

> On Sun, Jul 24, 2011 at 11:48 PM, Mac Ryan <quasipedia@xxxxxxxxx>
> wrote:
> 
> > Hi all,
> >
> > I'm pretty new to pygame (although I have good experience with
> > python) and this is my first message on the list. Bear with me if
> > what I am about to ask has been already discussed.
> >
> > While working around my first program, I realised that while each
> > sprite has an update() function, it's drawing happens at group
> > level, by blitting the s.image and s.rect directly, which somehow
> > limits this functionality (for example making impossible to set
> > blit flags).
> >
> > I was wondering if this was a design choice, and in that case,
> > what's the rationale behind it.
> >
> > I realise both that:
> >
> >  1. Calling a sprite function is expensive
> >  2. I can override the group.draw method to call a sprite function
> >
> > Yet it seems to me that having a sprite.update without a sprite.draw
> > is "inconsistent" from an API standpoint.
> >
> > I did not profile the code to see how big is the performance hit
> > because of #1, but #2 has serious limitations as a workaround: for
> > one, the draw() method changes in each an all of the group classes,
> > so if the sprite must use a draw method, one will have to override
> > _all_ of the draw methods of the types of groups used in the
> > program.
> >
> > Your thoughts?
> > /mac
> >