On Mon, Mar 10, 2008 at 7:54 PM, René Dudfield <[EMAIL PROTECTED]> 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?
