Re: [pygame] sprite engine

[DR0ID <dr0id@xxxxxxxxxx>]

Kamilche schrieb:
> > I'm interested in your code and if you allow it I would like to take 
> > a look  at it to see, if I'm on the right track or if things can be 
> > done better than I do.
> >
> >
> > ~DR0ID
>
>
> I'm sorry, I can't, because I've been working on this for a long time 
> now, and it will be a commercial product. I can say it's more 
> elaborate and complete than any UI/sprite system I've seen for pygame. 
> I haven't seen any open source or free code that does everything I 
> wanted, so I had to write my own.
>
> There is something you should take a look at tho - the best free UI 
> system I've seen so far, is Phil's Pygame Utilities. I seriously 
> considered modifying that to meet my needs instead of making my own... 
> but decided against it when I got to know it better. The tab system on 
> it is broken, it doesn't do fullscreen mode in Windows, the text 
> editing capability is low end, there's no formal event system to hook 
> into your sprite engine, there's an odd 'html form' orientation to it, 
> some resizing bugs, etc. I finally decided I'd rather make one from 
> scratch than fix someone else's bugs, but it was a close decision! 
> It's certainly good enough to cut your teeth on though, if you're 
> looking for example code.
>
> I'm happy to talk 'theory' though, big overview concept sort of stuff.
>
> --Kamilche
Hi

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