Re: [pygame] AGG library
Greg Ewing wrote: Maybe someone could take a few of the algorithms and manually template-expand them for the cases that will be used by PyGame? FWIW, I think PyGame could do with some better vector drawing routines as well. Some of the algorithms used by pygame.draw are rather rough-and-ready. We have pyrex based bindings for AGG which can draw to anything with start address and stride. They draw very simple SVG like scene. We plan to publish them if someone is interested. Nikolay Spahiev RD Manager Vintech Ltd.
Re: [pygame] AGG library
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?
Re: [pygame] AGG library
On, Tue Mar 11, 2008, Brian Fisher wrote: On Mon, Mar 10, 2008 at 7:54 PM, René Dudfield [EMAIL PROTECTED] 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 pgpFWvVOu2PEq.pgp Description: PGP signature
Re: [pygame] AGG library
Brian Fisher wrote: 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. AGG may be templated, but it is not a template library. After downloading it I notice the first step is to run automake. There is a source directory full of .cpp files that need compiling to libraries. Now we have a problem. We would have both a C++ Python extension module and separate C++ dependencies. And I am reasonably sure that the extension module and dependencies will have to be built with the same C++ compiler to work. So for Windows their is no including the AGG libraries in the prebuilts package. They will have to be built along with Pygame by distutils. The relevant pieces of AGG would become part of the Pygame source distribution and presumably included in SVN. There is also the task of working out the AGG build steps and adding them to setup.py. So how badly are the AGG features desired? -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] AGG library
On Tue, Mar 11, 2008 at 11:32 AM, Lenard Lindstrom [EMAIL PROTECTED] wrote: AGG may be templated, but it is not a template library. After downloading it I notice the first step is to run automake. There is a source directory full of .cpp files that need compiling to libraries. Now we have a problem. We would have both a C++ Python extension module and separate C++ dependencies. And I am reasonably sure that the extension module and dependencies will have to be built with the same C++ compiler to work. So for Windows their is no including the AGG libraries in the prebuilts package. They will have to be built along with Pygame by distutils. That doesn't sound right at all. There is no such thing as an agg library. There's just source code and some example files that include a portion of the AGG source. I think the only reasonable way to integrate with pygame would be to have a C extension module that was statically linked to compiled C++ source files. The relevant pieces of AGG would become part of the Pygame source distribution and presumably included in SVN. There is also the task of working out the AGG build steps and adding them to setup.py. The first sentence here sounds exactly right for how I'd see it going down - basically pygame would absorb agg source, just like it did for SDL_gfx for transform and draw. The second sentence sounds like a minor thing - the only AGG build steps would be compiling the cpp files that expose extern C functions to pygame. I would expect that works fine, cause I would think GCC's C++ backend is link friendly with it's C backend, just like it is with Visual Studio.
Re: [pygame] AGG library
On Tue, Mar 11, 2008 at 11:23 AM, Marcus von Appen [EMAIL PROTECTED] wrote: 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. Like I said, doing that kind of work with SDL_gfx sounds great. I just would love to have any new features I don't see in SDL_gfx, and I would think it would be better if new feature support in SDL_gfx that pygame utilizes come from an established tested lib that already has such features. And AGG is the only one I know that I think fits the bill. 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? display_surface.render(source_surface, pos=(100.5, 50.5), scale=(.5, 1), angle=45, color=(255, 128, 128, 128)) and then you would have source_surface drawn onto display surface rotated 45 degrees, red tinted, half transparent, squished to half size along the x and drawn at a subpixel position instead of clamping to integer. The art in this game here was drawn that way: http://wikgame.com/Gallery.html
Re: [pygame] AGG library
Brian Fisher wrote: On Tue, Mar 11, 2008 at 11:32 AM, Lenard Lindstrom [EMAIL PROTECTED] wrote: [snip] There is a source directory full of .cpp files that need compiling to libraries. That doesn't sound right at all. There is no such thing as an agg library. There's just source code and some example files that include a portion of the AGG source. I think the only reasonable way to integrate with pygame would be to have a C extension module that was statically linked to compiled C++ source files. Whether they are libraries or object files amounts to the same thing, C++ compiled files exporting C++ classes that need to link to a C++ compiled extension module that must work with those classes. Everything must be compiled with the same tools. But see below. [snip] The relevant pieces of AGG would become part of the Pygame source distribution and presumably included in SVN. There is also the task of working out the AGG build steps and adding them to setup.py. The first sentence here sounds exactly right for how I'd see it going down - basically pygame would absorb agg source, just like it did for SDL_gfx for transform and draw. The second sentence sounds like a minor thing - the only AGG build steps would be compiling the cpp files that expose extern C functions to pygame. I would expect that works fine, cause I would think GCC's C++ backend is link friendly with it's C backend, just like it is with Visual Studio. If AGG exports a pure C api then that could simplify things. But including AGG in SVN would do so as well. If the AGG source files can be compiled and linked without setting a bunch of platform dependent flags (e.g. macros) then doing so with distutils is straight forward. -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] AGG library
Richard Goedeken wrote: Brian Fisher wrote: I think it would be great for pygame and/or SDL_gfx to use [Maxim's] work to reach that level without having to do all the work he did. Ahh, but you're going to have to fight a C/C++ war to make that happen. Maybe someone could take a few of the algorithms and manually template-expand them for the cases that will be used by PyGame? FWIW, I think PyGame could do with some better vector drawing routines as well. Some of the algorithms used by pygame.draw are rather rough-and-ready. -- Greg
Re: [pygame] AGG library
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
Re: [pygame] AGG library
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
Re: [pygame] AGG library
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
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 [EMAIL PROTECTED] 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 [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
Re: [pygame] AGG library
Brian Fisher wrote: 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. Ahh, but you're going to have to fight a C/C++ war to make that happen. Good luck with that. :) I've seen this happen several times in my professional work. In the end, it comes down to where the people really driving the project want to go with it. If the pygame authors really want the advanced functionality of AGG then they'll find a way to make it work. If they decide it's too complex and to extend their own software libraries instead, then it'll go that way. But since it's open source, anyone can make a go for it. If it's easy to cobble the pieces together and make some impressive demos with aggdraw+numpy+pygame then someone who believes in it should just do it and show everyone how cool it could be. Maybe it wouldn't require major changes to pygame.
Re: [pygame] AGG library
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? As mentioned in another email, the choices are also SDL_gfx, cairo, tinyGL etc. The SDL_gfx is fairly nice for a small library, and the author has expressed interest in working with us. TinyGL gives us basic opengl in software support, and can also give us some 3d stuff we can use with a simpler API. AGG (if it supports buffers) can be used with just pygame, because it supports using buffers without numpy or numeric now. On Tue, Mar 11, 2008 at 1:32 PM, Richard Goedeken [EMAIL PROTECTED] wrote: Brian Fisher wrote: 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. Ahh, but you're going to have to fight a C/C++ war to make that happen. Good luck with that. :) I've seen this happen several times in my professional work. In the end, it comes down to where the people really driving the project want to go with it. If the pygame authors really want the advanced functionality of AGG then they'll find a way to make it work. If they decide it's too complex and to extend their own software libraries instead, then it'll go that way. But since it's open source, anyone can make a go for it. If it's easy to cobble the pieces together and make some impressive demos with aggdraw+numpy+pygame then someone who believes in it should just do it and show everyone how cool it could be. Maybe it wouldn't require major changes to pygame.
