Re: Moving frozen Bubble to the new SDL API

Kartik Thakore

On 5-Feb-10, at 10:01 AM, Guillaume Cottenceau <[email protected]>  
wrote:

>>>> HI Guillaume,
>>>>
>>>> Since most of the new SDL API is ready for frozen bubble I have  
>>>> started
>>>> to
>>>> move FB over to it.  Here is my work so far
>>>> http://github.com/kthakore/frozen-bubble/tree/redesign you will  
>>>> need the
>>>> SDL_perl from here http://github.com/kthakore/SDL_perl/tree/ 
>>>> redesign
>>>
>>> Why have you removed the sugar in your new sdlpl?
>>
>> The new SDL bindings are pure bindings because there was way two much
>> coupling between the sugar and bindings in the last api. We are  
>> going to add
>> the sugar back in with a seperate SDLX:: layer. The idea is for  
>> each library
>> to do one thing and do it well. The modularization also allows us  
>> to split
>> that behemoth SDL.xs file. This way bugs and feature are easier to  
>> fix and
>> add.
>
> It seems to me better to write your SDLX:: layer then use it from the
> applications (frozen-bubble), rather than modify all the applications
> (frozen-bubble) calls to sdlpl then?
>
This might be a better idea. Maybe I rushed ahead a little.

> Also, there needs to be an update strategy for applications. It is
> very helpful that a compatibility layer exists. For example, FB was
> designed with sdlpl 1.x, and as sdlpl 2.x was not compatible with it,
> or I didn't know how to do it, I finally had to write the "surf" sub
> and friends to be able to use both versions, and let distros upgrade
> smoothly. This creates problems. Or your new SDL needs to be parallel
> installable with the old one, and FB would be migrated to using the
> new one only months after the new one is released, to wait for
> propagation in distros.
I think we can do the second one. Maybe we can seperate the SDL view  
code from frozen bubble main logic so that we can swap SDL versions.  
Sort of like an interface. Similar to how DBI does it. What do you  
think?

>
>
>>>> Since there are no comments here I am at a loss. Currently  
>>>> SDL::Surface
>>>> as
>>>> Opaque Objects in the typemap to prevent memory leaks. You can  
>>>> see the
>>>
>>> Why being opaque prevents memory leaks?
>>
>> Because opaque objects can be handed over to Perl for gc and thus get
>> DESTROYed at the right time. Also our opaque objects now keep track  
>> of which
>> perl thread they have been create. This was the library is thread  
>> safe down
>> to the object.
>
> I don't see why a scalarref cannot make use of the DESTROY to reclaim
> memory, but I'm not fluent in XS and stuff.
>
> -- 
> Guillaume Cottenceau - http://zarb.org/~gc/