[pygame] FastRenderGroup revised (update4)

[DR0ID <dr0id@xxxxxxxxxx>]

Hi

Today I got the time to do the changes you have suggested in the last email.
You can download it here:

http://www.mypage.bluewin.ch/DR0ID/pygame_projects.html#fast_dirty1
or direct link:
http://www.mypage.bluewin.ch/DR0ID/pygame/FastRenderGroup_v1.1.78.zip



1.) Change the name: yes, but to what?

2.) you really want to be able to pass in different get_ticks() 
functions? I can do it, but I do not see the benefit, because I'm still 
unhappy with the solution how to decide which method to use. Perhaps I 
could use a Exponential back off strategy (do not know how to implement 
it), but I'm not sure if that would be good. Any better ideas?

3.) naming of the attributes of the DirtySprite: we can change them, but 
to what? Are the current names already used?

4.) I don't think we can make it backwards compatible, so it will not 
replace RenderUpdates (unless the pygame.sprite.Sprite becomes the 
DirtySprite with dirty=2 as default, but that would be stupid).


I have modified testsprite.py to use FRG, please test following 
configurations:

testsprite.py
testsprite.py -update_rects
testsprite.py -FastRenderGroup

testsprite.py -static
testsprite.py -static -update_rects
testsprite.py -static -FastRenderGroup

What do you think? For that tests I have added a new image, as you can see.

I have written a demo to demonstrate that all sprites have to be in the 
same FRG to be drawn correctly:

multi_FRG_demo.py

use the same arguments as for testsprite.py and you will see what 
happens when using the FRG.

If you run the testsprite.py you will have the frame jerking too, so it 
is not a problem of the FRG. To avoid the jerking you will have to limit 
the Framerate to certain frames per second(or put a sleep(0.001) in 
there somewhere).


I can not participate at the next minisprint, but in a week I will have 
time.


~DR0ID