Well, there are 100's of games using pygame.draw, and pygame.transform already. I don't think calling them mediocre is very nice, or accurate.
On Tue, Mar 11, 2008 at 12:19 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > I looked into aggdraw a long time ago - I don't think it can operate > on buffers. So I don't think it can be done right now. > > But even if it could be done right now, I'd still say that pygame > should get much better written in C/C++ drawing and rotation software > rendering code as a standard part of it's distro. I agree pygame > should be an SDL wrapper first, but pygame includes SDL_gfx which > provides mediocre drawing abilities and a pretty confusing and not > good rotozoom function, which a lot of pygame users try to use. Even > if people could get better drawing by finding and installing some > other extension, then passing buffer and pitch and semantic color > decriptions for their surface contents through to that extension for > drawing, I guarantee you the first instinct of the vast majority of > pygame users would be to utilize the included draw and transform > functions. > > Basically the way I see it is pygame does drawing and transforming on > surfaces in software, but does not do any of that very well. Utilizing > part of the agg code could make those things that pygame already does > really fantastically great. So why not? > > > > > On Mon, Mar 10, 2008 at 6:08 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > > Yeah, this could be done right now. > > > > > > > > On Tue, Mar 11, 2008 at 12:01 PM, Douglas Bagnall > > <[EMAIL PROTECTED]> wrote: > > > > > > I've not used it (nor have I fully followed this thread) but Fredrik > > > Lundh has written a python AGG wrapper[1] which works on PIL > > > images and other arrays. > > > > > > Rather than bringing everything into pygame, it seems better to me to > > > expose internal pygame arrays to external libraries, perhaps using the > > > Numpy array interface[2], so people can draw using whatever they want. > > > Assuming that using AGG already implies a software surface, there > > > doesn't need to be any overhead in accessing the pixel data from outside > > > of pygame. Pygame doesn't really need to be anything but a good > > > friendly SDL wrapper. > > > > > > probably missing something, > > > > > > Douglas > > > > > > > > > [1]http://effbot.org/zone/aggdraw-index.htm > > > [2]http://numpy.scipy.org/array_interface.shtml > > > > > > > > >
