Re: [pygame] extending mask module?

["Nirav Patel" <olpc@xxxxxxxxxxxxxx>]

I've still got checking in convolution on my to do list.  I've been
busy with school, but winter break is coming up soon.

The mask module is kind of strange because the Python additions were
all after the fact.  bitmask.c and bitmask.h were/are a separate C
library that is just included in Pygame.  That explains the exported
functions in bitmask.  I'm not clear on exactly what you wanted to do,
but it seems that the PyMaskObject and PyMask_Type definitions should
be in pygame.h instead of mask.c.  Then it would just be a matter of
including pygame.h and bitmask.h in what you are writing.

On Tue, Dec 2, 2008 at 9:32 PM, Michael George <mdgeorge@xxxxxxxxxxxxxx> wrote:
> One of them is the convolution code that I actually posted a while back but
> hasn't been checked in.
>
> Another is a method to find the closest position to a given one with the
> corresponding bit unset.  That seems much less generally useful.
>
> I'm also working on some more complicated code to support drag and drop of
> stretched rope-like objects.  Those are likely to be very special purpose,
> and rather complicated.  I think they'll need to be in C to be fast enough
> for me though.
>
> Is the only problem with non-static methods name clashes?  Because I'm not
> sure what the difference is between, for example, the functions in SDL which
> are visible, and the functions in bitmask.c.  If that's the case, then I can
> just expose the PyMask_AsBitmap and PyMask_Type through a C Object, and link
> my code against bitmask.  Understanding the build system(s) is a bit
> daunting.
>
> --Mike
>
> René Dudfield wrote:
>>
>> 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
>>>
>>>
>
>