Kartik Thakore
On 5-Feb-10, at 10:01 AM, Guillaume Cottenceau <gcott...@gmail.com>
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/
