Pygame weekly mini sprint 2007/06/20
I spent some time looking at the FastRenderGroups code by DR0ID.
I sent a first review to the mailing list about FastRenderGroup. So we can discuss some of the things we need to do to it before getting into pygame. It has a number of features missing from the current pygame sprite code. Including being adaptable when updating the whole screen, or just parts of the screen is quicker, as well as layers and support for the new pygame blending modes (like additive blending).
ideasman_42 came along and noted a few reference counting bugs in pygame. He also plans to send in a patch with a few speed ups - by avoiding PyArg_ParseTuple when not needed, and using METH_NOARGS when appropriate.
I started on a mask.from_surface() function, but got caught up finding a bug when printing a surface. I think that was caused by the last set of changes to surface. I wrote a unittest for it, and submitted the bug to the mailing list.
Richard Goedeken submitted a patch for a smooth scaling function for pygame.
You can read about it here. It comes with an mmx function. However pygame doesn't have the infrastructure set up yet to support mmx or other asm optimizations. So we plan to use the cpu detection code that SDL uses.
I sent a first review to the mailing list about FastRenderGroup. So we can discuss some of the things we need to do to it before getting into pygame. It has a number of features missing from the current pygame sprite code. Including being adaptable when updating the whole screen, or just parts of the screen is quicker, as well as layers and support for the new pygame blending modes (like additive blending).
ideasman_42 came along and noted a few reference counting bugs in pygame. He also plans to send in a patch with a few speed ups - by avoiding PyArg_ParseTuple when not needed, and using METH_NOARGS when appropriate.
I started on a mask.from_surface() function, but got caught up finding a bug when printing a surface. I think that was caused by the last set of changes to surface. I wrote a unittest for it, and submitted the bug to the mailing list.
Richard Goedeken submitted a patch for a smooth scaling function for pygame.
You can read about it here. It comes with an mmx function. However pygame doesn't have the infrastructure set up yet to support mmx or other asm optimizations. So we plan to use the cpu detection code that SDL uses.
Comments
I've done something like FastRenderGroup, please look at http://blog.gustavobarbieri.com.br/2007/04/03/pygame-smart-group-and-sprite-implementations/
Also, I'm now working with Evas, it does this really well, you can base your work (it's BSD). I rewrote their evas_tiler.c, used to get dirty areas, avoid overlapping rectangles and also do merge so number of rectangles are kept low. Algorithm is really fast and well implemented, you can get it and I give you the permission to relicense: http://blog.gustavobarbieri.com.br/2007/06/03/evas-now-using-rectangle-split-and-merge/
There is also SVN versions:
- Pygame SmartRender: http://barbieri-playground.googlecode.com/svn/pygame/smart_render/
- Rectangle Splitter: http://barbieri-playground.googlecode.com/svn/rectangular-areas/
Rectangle splitter in evas_tiler.c is kind of faster since I use cache for list nodes and I also implement del_redraw() operation.
I'm not sure if I can help at this sprint, but keep me informed, I really want pygame to have this so I don't have to maintain my own version and others benefit too. My mail is: barbieri-at-gmail.
ah, I've never seen your work before. It looks quite interesting.
Perhaps we can use some of your ideas in the pygame sprites.
Evas has always looked pretty cool. How do you like it compared to SDL/pygame?
Recently we added a mask module which can do things like quickly finding collisions between sprites. But also might be able to be used to quickly find out which areas to update on the screen.
A good place to talk about this stuff would be the pygame mailing list if you want.
Cheers,
About how Evas relates to Pygame and SDL, evas is much higher level than SDL, providing something like PyGame does with its Sprites and Groups. The good thing, and the reason we've choose it to replace SDL in our company is due great frameworks built on top, like ETK (GUI toolkit), Edje (theme system), Emotion, ... it would take huge amount of time to build that ourselves or trying to fix some unmaintained code like pyui.
I know PyGame is really tied/close to SDL so moving is difficult, but maybe you can use Evas and Edje somehow, just look at my python-bindings at:
http://www.enlightenment.org/
CVS: e17/proto/python-efl/
PS: http://blog.gustavobarbieri.com.br/2007/06/22/efl-on-n800-packages-and-video/