[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] AGG library
ummm... the way you phrased that really makes it seem like I'm
insulting people's games... to be clear I was not calling the games
made with pygame mediocre at all - I was calling the draw and
transform capabilities that pygame includes mediocre. People have been
doing an excellent job making great games with the capabilities that
have been provided - I just think more useful and feature rich
capabilities would be great because people could make even better
games with less time.
I'm sorry if my correspondence on this list has been not very nice. I
suppose "minimalistic" would have been a more diplomatic choice of
term than "mediocre". I apologize if I implied that anything about the
development of pygame or SDL_gfx has been deficient or of poor quality
to this point. I don't feel that way at all.
My own poor choice of phrasing notwithstanding, Maxim has put his time
and energy into getting the capabilities of AGG's drawing and
transformation code to places that achieve a lot more than SDL_gfx and
pygame.draw & transform have achieved. Since he shares his work so
generously, I think it would be great for pygame and/or SDL_gfx to use
his work to reach that level without having to do all the work he did.
On Mon, Mar 10, 2008 at 6:26 PM, René Dudfield <renesd@xxxxxxxxx> wrote:
> 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
> <brian@xxxxxxxxxxxxxxxxxxx> 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 <renesd@xxxxxxxxx> wrote:
> > > Yeah, this could be done right now.
> > >
> > >
> > >
> > > On Tue, Mar 11, 2008 at 12:01 PM, Douglas Bagnall
> > > <douglas@xxxxxxxxxxxxxxx> 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
> > > >
> > > >
> > >
> >
>