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

Re: [pygame] extending mask module?



Hi,

Maybe submit your extensions for inclusion?  That might be the
easiest.  What extensions are they?

It'd be nice for any fix ups to mask... it's got a few issues.
However making a C API for it is not a priority at the moment...
Marcus has done some work on it for pgreloaded (see a branch in svn).
http://www.seul.org/viewcvs/viewcvs.cgi/branches/pgreloaded/src/mask/?root=PyGame

If you'd like to submit changes for making a C API similar to how it's
done in pygame for other modules, that'd be cool too.

An issue with making functions static is that then they can have
issues being multi threaded if they release the python GIL.

... so I think it'd be best to submit your extensions into pygame I
think.  Since there's no real C API at the moment.  Then we can make
sure your extensions are in pyreloaded too.



cheers,


On Wed, Dec 3, 2008 at 12:36 PM, Michael George <mdgeorge@xxxxxxxxxxxxxx> wrote:
> Greetings,
>
> I have some extensions to the mask module for my game, and I'm trying to
> figure out how to build/package them.  For the sake of getting it working
> I've just hacked them into the pygame source and been building a custom
> pygame, but obviously that's not a good solution.
>
> However as I'm trying to tease it out of there I'm coming across some
> confusion.  It looks to me like the mask module violates the "everything
> static except initmodule" rule, because the functions in bitmask.c are
> exported, and AFAICT bitmask.c is linked into the mask module.
>
> Part of the reason this is a problem is because the mask module doesn't seem
> to export any kind of C API like the other modules do.  It would be useful
> to me if the bitmask_* functions were exported.
>
> I'd be happy to spend some time and submit a patch, but I'm not quite sure
> how it should work.  Should mask.c access the bitmask.c functions through
> the exported function table?  Should mask.c just #include bitmask.c?  Any
> thoughts?
>
> --Mike
>