-=-=- d...@nexttolast.com -=-=-
On Sep 1, 2009, at 8:56 AM, Guillaume Cottenceau gcott...@gmail.com
wrote:
or urpmi :)
I know, I know, mandriva is just not hype anymore..
Was it ever :)
Thanks. Well, I can't remember how I first tried sdl-perl. I surely
don't like/use cpan a lot, so
-=-=- d...@nexttolast.com -=-=-
On Sep 1, 2009, at 9:25 AM, Kartik Thakore thakore.kar...@gmail.com
wrote:
If you remember or can find them some of the bugs. Can you post them
onto RT?
If Guillaume can remember a single bug from those days without looking
it up I'll buy him a beer
On Mon, Aug 31, 2009 at 11:54 AM, Kartik
Thakorethakore.kar...@gmail.com wrote:
What if this was fixed with Alien::SDL as it is doing for windows now? Kmx
is also working on strawberry compatible makefiles. This way we can compile
for most platforms from scratch.
The problem is as Andreas
The answer is use DESTROY. And there was at one point a SDL::free
method, but who knows if is still around.
Best advice on mem leaks is stop doing that. And by that I mean what
your doing. You should never assume that it is safe to free anything
when dealing with complex systems.
Just a historical FYI. I did a version of the thunk based calls for
Sdl Perl in around 2k2 and it works ok. The real issue is not the
several C ABI variants that need to be supported (6 main ones with
slight variants) the problem is Making some of the calls perlly.
So if we are ambitious
kartik,
I have a Windows instance that I use for testing builds, but it is dumped on
a backup tape somewhere. Let's try to unravel what we really need to
produce a more friendly build system. Also in the 2.2.x branch, there is
the preliminary work for a MacOS X applet dropper, and I'd like to
Since Kartik Thakore has expressed interest in getting SDL Perl back
in gear, I'm going to help the SDL Perl community get back into the
swing of things.
At the request of Carlo zED Caputo and Rodolfo Borges, I moved the
development repository off of a now defunct SVN server, into github.
The new
Since Kartik Thakore has expressed interest in getting SDL Perl back
in gear, I'm going to help the SDL Perl community get back into the
swing of things.
At the request of Carlo zED Caputo and Rodolfo Borges, I moved the
development repository off of a now defunct SVN server, into github.
The new
I'll pull review and merge.
Dave
-=-=- d...@nexttolast.com -=-=-
On Aug 2, 2009, at 11:39 AM, Kartik Thakore thakore.kar...@gmail.com
wrote:
Now SDL_perl has support for
OpenGL gluquadric* stuff.
an example is made available from NeHe lesson 18. (GL_SMOOTH doesn't
seem to work)
The file
not the test is broken, and not the underlying code), I'm in no rush to
fix them. Volunteers are more than welcome to take on that task.
Thanks for the report
Dave
John Gabriele wrote:
On 3/11/07, David Goehrig [EMAIL PROTECTED] wrote:
Everybody,
I just went through the build process on Mac OS
Everybody,
I just went through the build process on Mac OS X and Debian, and fixed
up a few bugs that were created as a result of a change in Module::Build
that I've been too lazy to correct, and a few other bugs that cropped up
as part of getting the SDLPerl.app bundle working under MacOS X.
Hey all,
I'm around but busy as usual. Subversion is still up at
http://nexttolast.com/sdlperl
And always collecting submissions.
Sorry I haven't been pushing out much code, but life keeps getting in
the way :)
Dave
Tels when you checkout of the repository you create your own Local branch.
When you've finished testing and verified that your code is right,
check it in to the main tree.
When a release is made, for sanity sake, I will import the release as
another branch. All development should happen in the
About merging branches. I want to point out that most of the branches
are incompatible with the current version of SDL perl internally. The
SDL_perl-2.2.0 release which is in SVN right now is based on the major
rewrite were we moved to blessed scalars for the entire OO layer, and
made lots of
Ok, I took a few minutes out to change the configuration of my
webserver and added a new repository, uploaded my current working
code, and set the SVN repository up.
http://nexttolast.com/sdlperl
Anyone can make changes, but when you do please send me an email
telling me what you did. If I do a
Well I've spent too many of the past 48 trying to get SDL Perl up an running
on my PowerBook. I will totally admit SDL Perl was truly broken on the Mac
platform. What this effort has resulted in though, is something rather
different. I'm a few hours away from putting together an SDL Perl.app
Hey all,
I've uploaded the lastest buildable revision 2.1.1 to
http://sourceforge.net/projects/sdlpl/
You can download the tarball there. I haven't yet
integrated the build changes to this version, this has
only the feature improvement / bug fixes patched.
Build system bug fixes comming
I just figured out what changed and broke the OpenGL
stuff, it was a bootsrap code change.
Previous versions automatically loaded the OpenGL.so
if you had it, regardless of if you need it.
In fixing that the export of the functions into the
main namespace by including SDL::OpenGL failed,
because
What is not the official SDL perl
release/repository?
CPAN is going to be the release repository.
Andreas finally fixed the permissions and I
can finally submit distributions again.
Is David just using sdl.perl.org?
I am in full support of using sdl.perl.org
and I'd recommend we get a wiki
--- Scott R. Godin [EMAIL PROTECTED] wrote:
Also CPAN thinks it's version 2.0 not 2.0.5
yeah CPAN has a lot of screwy ideas. There
were problems with the distribution import
and so the metadata got kinda screwy
snip installing from CPAN
As for the install failure, it looks like it is that
In the 2.0.5 branch there is a method
SDL::Surface::rect ([x,y])
which retuns a SDL::Rect with the given x,y
(0,0) if not specified.
usage
my $app = new SDL::App;
my $image = new SDL::Surface -name = 'player.png';
$image-blit(0,$app,$image-rect(10,20));
Usually I subclass Surface into
21 matches
Mail list logo
