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

Re: [pygame] AGG library



On, Tue Mar 11, 2008, Brian Fisher wrote:

> On Mon, Mar 10, 2008 at 7:54 PM, René Dudfield <renesd@xxxxxxxxx> wrote:

[...]
> >  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.

It's more a general bug-fixing and making SDL_gfx more platform-neutral
where necessary so we can incorporate its code easily (as done in some
functions already) and/or link to it using an own module. So the code
and information flow will go in both directions.
 
> >  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

No, but those can be received and calculated by the information, the
Surface object describes. We also can enhance the BufferProxy object to
provide such information.

> 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.

We do that for numpy already in pure python code using buffers. What
other special information would agg need to deal with the surfaces
properly?

We also had that idea about a pygame.sdl GSoC, which will succeed over the
stalled PySDL wrapper. Once done we also can use the additional
information provided by it.

[...] 
> 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.
[...]

"scale angle color and sub-pixel position" sounds like some typical
bullshit bingo phrase ;-). Can you give an example about what a result
of this operation will look like?

Regards
Marcus

Attachment: pgpYayW7S25bC.pgp
Description: PGP signature