Thanks for your fast response. It's ok to not show the code if it will
be a commercial product. So lets talk a bit about theory.
I though that to be fast, the screen update area has to be as minimal as
posible (so, essentially this means that do not update a pixel twice).
So far this is still a problem to solve for me because I do not know how
to do this in a fast way.
The second thing was that most information (especially not changing) has
to be stored by the renderer to have fast acces ( dereferencing can slow
things down).
And the other thing is to minimize the information needed. I think one
need following thing to know about a sprite:
image
rect
oldrect
dirty
area (attention to when rect/image size changes!!)
layer
lostrects (only for renderer)
(perhaps in future: blendmode)
In my code I store oldrect, layer and lostrects in the renderer itself.
But I wanted also that one could use the pygame.sprite.groups (except
draw() and clear() ), so that one could code the same way as till now.
But perhaps this has to change altough so far it was not a big problem.
I finally came up with following way to implement my sprite engine (very
general):
1. find screen update area (area on screen that has to be updated, as
minimal as possible)
2. blit any sprite that has a part in a screen update area (in the right
order of layers!)
The area in point 1. are all areas where sprites has to be removed
(cleared) from screen and area that has to be redrawen (essentially
oldrect and rect). Also the sprite that has been removed (lostsprites)
generates a screen update area.
The 2. point is easier. Check every sprite on collision with a screen
update area and if so blit it.
Perhaps it can be done in a better way. So what do you say to me
algorithme?
~DR0ID