Re: [pygame] FastRenderGroup revised (update4)

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

Hello,

very nice work!

I'm a bit busy myself for the next week.  So in two weeks would be a good time to meet up and finish off the last things before we put it into pygame.

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

Not sure.  I'm afraid of using 'Fast' because too many times I have seen projects where there is a new FastSomething only for it to eventually not be fast anymore a year later.

What are the main features of FastRenderGroup?  

We should definitely let people know in the docs that FastRenderGroup is the preferred group to use.


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?

So people can use their own game timers.  Say the rest of the game uses either time.time, or even something from blender, crystalspace, a real time clock etc etc.  Should definitely use a default timer though.

The jerking stops for me when I make it not oscillate between update, and flip modes.  I think maybe an Exponential back off strategy might work... not too sure.  I think we should try a few different things when we meet up in two weeks.

Some possible different strategies:
- figure out the best rendering method in the first 1-3 seconds, then stick with that.
- keep checking to see which is the fastest way.  Only change modes at most once every 10 seconds.


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

Haven't had a chance to research this.  Let's look at it in two weeks.

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

Cool, that's fine if we can't.

btw, Gustavo posted about some code he's done for fast sprite usage:
http://renesd.blogspot.com/2007/06/pygame-weekly-mini-sprint-20070620.html#comments

I think his approach is to break the screen up into tiles of 8x8.  Then in the sprite code mark each tile as dirty, if the sprite needs to be updated in those positions.  This way there is a constant number of rectangles passed through to the update function every frame - and no over draw.

On 6/30/07, DR0ID <dr0id@xxxxxxxxxx> wrote:

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