Re: [pygame] FastRenderGroup (update 3)

["René Dudfield" <renesd@xxxxxxxxx>]

Hi,

just to let you know I'm looking through your FastRenderGroup today.

Here's some initial thoughts.

- it is quite well documented.

- it's great that you factored out the Layered part.

- seems to run faster than RenderUpdates.  It'd be nice if you could
incorporate FastRenderGroup into the pygame example/testsprites.py  I
sent you a copy earlier where I started to integrate it.  So that via
the command line people can choose to use FastRenderGroup or other
methods.  That is the place where the rest of the other sprite stuff
is performance tested, so that's the place to put FastRenderGroup too.

- we could put your fast renderer group demo into the pygame examples
too.  Since it shows off lots of other features of FastRenderGroup
that none of the existing demos do.

- readonly/private variables should use an underscore.  eg
DirtySprite.layer maybe should be ._layer.  I think you have done this
already mostly.

- Maybe we could use incorporate DirtySprite's features into the
pygame.sprite.Sprite  Since all the differences are is a few
attributes.  This needs more thought on attribute naming.  We don't
want conflicts with existing pygames - if we add them to
pygame.sprite.Sprite.

- documentation is needed by some methods.

- The frame jerking is weird.  We'll need to fix this before it's used I think.
   - add a print 'flip' into the draw method, and you will see that
the jerkiness is caused by it occasionally flipping, rather than
updating.  This causes the fps difference, and shatters the illusion
of movement - which requires a constant fps.


- I'm not sure how to have make FastRenderGroup backwards compatible
with RenderUpdates.  However if it was backwards compatible, then we
could completely replace RenderUpdates.  Maybe a question to ask is...
why is it not possible to make it backwards compatible?

- the unittests should be in a separate file.

- I think maybe a name change for the FastRenderGroup?

- I'm not sure about the use of get_ticks().  I think it's ok, because
you're not doing animation with it, just figuring out which update
method to use.  Some tests with different get_ticks() functions are
passed in could allow you to unittest your switching behaviour.

- what disadvantages does FastRenderGroup have over RenderUpdates?
These are the ones I can see so far:
    - needs to use DirtySprite, not normal pygame Sprites. (We could
fix this by giving normal pygame sprites the DirtySprite default
attributes)
    - all sprites have to be in a single group.  ( Why do they need
to be? Is this really a problem at all?  Can it be solved easily?)


Ok, that's all for now.  Just email again to the list, if you don't
catch me in irc.  Hopefully we can figure out some of these issues,
then put it in pygame.  Or should we just put it in pygame now, and
fix things in there?

Cheers,


On 6/12/07, DR0ID <dr0id@xxxxxxxxxx> wrote:
> Hello again
>
>
> Here comes Version v1.1.72 of the FastRenderGroup!
> Download:
> http://www.mypage.bluewin.ch/DR0ID/pygame_projects.html#fast_dirty1
>
> Changes:
>
> -Layersystem is now in a separated LayeredRenderGroup (you can use that
> with the old pygame.sprite.Sprites)
> -it comes with an unittest class for the LayeredRenderGroup and is
> therefor working
> -FastRenderGroup now works only with the DirtySprite, but I'm open to
> suggestions if it should be compatible or not with the old
> pygame.sprite.Sprites and how to do it
>
>
>
> Please take a look and i would appreciate some feedback. Sorry for the
> delay, but now it is here :-)
>
>
> Thanks
>
> ~DR0ID