Hello, I don't think we should rely on SDL_gfx being installed.
Contributing to SDL_gfx is great if we can do that. However by relying on an extra dependency it will mean we won't be able to rely on that functionality being there. So if we factor out SDL_gfx back into a library we need to still include it with the pygame build process to make sure that if pygame installs ok, then all that functionality will work. On 8/22/06, Phil Hassey <[EMAIL PROTECTED]> wrote:
(My main summary post from earlier today stands as my definitive opinion. But here is some more general blah blah blah from me ;) ) Sure. However I have these planned... I already have a basic ADD 32bit blit routine written, and plan to make mmx versions for each of the new blit routines which were written in C. This same code could be used for pygame ctypes if it wanted. For example the current pygame draw, image, and transform modules should be able to be used from pygame ctypes. So maybe there is no point in rewriting them in C for pygame ctypes since they already exist in pygame. Actually, we should probably contact the author of SDL_gfx (okay - I've CCed him this) and see if we can get some of our stuff added to that library. SDL_gfx is already included in many distros and (I think) pygame depends on it already. All the blending code we (Rene and I) worked on would do well to be added to that library. I have some other line and circle drawing functions I would like to see in pygame, but would probably do better to have them added into SDL_gfx and then added into pygame. (My line and circle drawing stuff is ultra-nice-anti-aliased, with support for all blending functions.) Again, this would be a way for pygame and pygame-ctypes to have additional functionality that would be readily available from a standard library of sorts. Phil ________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta.
