[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] AGG library



On Mon, Mar 10, 2008 at 7:54 PM, René Dudfield <renesd@xxxxxxxxx> wrote:
> One issue is code size, and dependencies.  AGG is nice, but quite big
>  and complex.  So including it in pygame might be a bit of a problem
>  maintenance wise.  Is the older non-GPL version being maintained by
>  anyone?
>
AGG is a templated system for building custom software graphics
pipelines with a huge set of pieces already implemented. So in the end
the compiled code size is essentially only what you used. It's similar
with the complexity in that you can ignore parts you don't care to
use.

As far as maintenance goes, no Maxim isn't maintaining 2.4 (he hasn't
done anything with 2.5 lately either). However in my mind this is a
very minor issue - since it has no dependencies itself, it will
continue to work as it does as long as well-written C++ template code
still compiles, and it's very well tested (we've used it at work for 5
games over a couple years and only found one minor bug that was
already fixed in 2.4 by the time we found it in 2.3). I figure we'd
just have the sources we use in pygame and fix what little things may
come up.


>  The SDL_gfx is fairly nice for a small library, and the author has
>  expressed interest in working with us.
>
SDL gfx doesn't have support for things I'd like to see get in pygame
soon. I'd love to work with adding such things to the sdl_gfx library
if he'd want to use some well tested developed existing
implementations - but if it came down to helping write new
implementations of things it seems like it would be a lot of extra
effort to me.


>  TinyGL gives us basic opengl in software support, and can also give us
>  some 3d stuff we can use with a simpler API.
>
I think openGL's stack and texture model produces a not great API for
good 2d software rendering, and it's really fairly bad for shape
rendering what with having to do poly tesselation and cubic curve
subdivision for non-convex curved shapes. Does TinyGL make any of that
stuff easier? Does it support polygon smooth for instance? I'd still
much rather see something that just plain works with pygame
surfaces...


>  AGG (if it supports buffers) can be used with just pygame, because it
>  supports using buffers without numpy or numeric now.
>
So do python buffer objects expose pitch and element size to C
extension code? If so they might work OK, but it would still be on the
coder to resolve communicating details of the pixel format between
pygame and the drawing code, right? I'd rather see the pygame code
automatically deal with picking the right drawing code based on
surface details. AGG has code already that deals with SDL surfaces.


... writing this email, I realize a lot of reasoning about how to best
accomplish draw and/or transform improvements is much easier when the
draw and transform improvements are clearly understood/articulated, so
it's probably good to talk about what such improvements should be.

The big 3 things I'd want to add are:
1. being able to render a surface at a scale angle color and sub-pixel
position into another surface and have it blend with the target
surface coordinates.
2. being able to construct an arbitrary shape of multiple extents with
lines and bezier curves and then be able to render that shape's
outline or it's interior either textured or with a solid color.
3. being able to gaussian blur a surface in place efficiently (meaning
done as 2 1d convoutions)

So any reason not to make those additions? anything else that people
would feel would be more useful?