[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] FastRenderGroup (update 3)

Hello
thanks for your response, although I do not have much time for the next 2 weeks. I have not looked at the testsprites.py very close, but I will as soon I have some time, so some answers/questions may be a bit inaccurate. 

René Dudfield schrieb:

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.

Yes it should thanks to the dirty technique.



- 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.


Sure, what features exactly do you mean?



- readonly/private variables should use an underscore.  eg
DirtySprite.layer maybe should be ._layer.  I think you have done this
already mostly.
Agreed, I will put the file through "lint", so it should match standard python ( http://www.python.org/dev/peps/pep-0008/ ) 



- 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.
well yes, naming is a delicate topic, any help appreciated (I do the refactoring, no problem). 



- documentation is needed by some methods.
Sure, tell me which ones. Oh, I have just seen that I forgot to document the FastRenderGroup itself. If someone has started to use either the LayeredRenderGroup or the FastRenderGroup and has found the doc's to be inaccurate, please let me know how to improve the docs. (because docs are valuable information). Thanks.
- 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 think the frame jerking is cause because I use 100% cpu and from time to time the OS has to do other things. If you put in a pygame.time.sleep(0.002) it will stop jerking, but the framerate drop too. 



- 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?
Because I need more information like a dirty flag (well if the Sprite has it then it could be possible, but then the question is what default value to use). Main reason are the attributes. 


- the unittests should be in a separate file.
ok, can someone look through them and give me some advise how to do them correctly? I have done them in the best way I thought, but perhaps wrong way (its actually the second unittest i have written so far). 


- I think maybe a name change for the FastRenderGroup?
Sure. Just wondering what you think is wrong with that name? Any proposal welcome since I though it was a good name. 

- 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.
Hmm. Im not sure if I fully understand you. I should pass get_ticks to the draw function so different versions could be used and therefore unittested? 


- 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?)
Well, this is due the redrawing of all srpites in a dirty area on screen. The dirty area on screen can affect sprites that are not dirty and therefor not redrawn (only the part that is in the dirty area is repainted actually). And that is the problem: the group must know all sprites on screen, otherwise it can not redraw them correctly.
Actually it would be simpler if you or I write some demo to demonstrate the effects which can occur when using more than one group simultaneously. 


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?
I would like to discuss these issues before putting it into pygame, although changes later in pygame are possible too. 


Any other opinions is welcome too. :-)
I will write again to the mailing list as soon I have resolved some of the issues you have mentioned earlier. But some must be discussed first. And as said the next two weeks I really do not have time as much as I wish I would have. 

Thanks.

~DR0ID