Re: SDL 2.541_02 Released

[Tobias Leich]

Ya, it should.

So in the test it can read the file as an SDL::RWOps-object, but
SDL::Mixer::Music::load_MUS_RW can't handle it.
A few lines later SDL::Mixer::Music::load_MUS($ogg_test_file) failes too.

I'll check my VMs this evening, maybe I can reproduce that thing.

Am 11.06.2012 01:08, schrieb Jeffrey Palmer:
> This problems still occurs occasionally with Alien-SDL 1.434
>
>  
>   http://www.cpantesters.org/cpan/report/04921c82-b30c-11e1-9066-3d54fb7543f5
>
> I created an issue about this a while ago:
>
> https://github.com/PerlGameDev/SDL/issues/233
>
> The build option include ogg, but those same tests fail.  Should those
> tests pass with those build options?
>
> Jeff
>
> On Sun, Jun 10, 2012 at 1:21 PM, Tobias Leich  > wrote:
>
> Ya, would be sweet to make another dev release, requiring a newer
> Alien::SDL.
>
> Check t/mixer.t for audio support, its basically just that you try
> to init OGG, and skip if it fails.
>
> Am 10.06.2012 18:03, schrieb Jeffrey Palmer:
>> So are we ready to bump our Alien::SDL prereq (at least in the
>> dev release)?  Also, I'm assuming we should skip these tests if
>> libogg support isn't available.  What's the proper way to detect
>> audio format support?
>>
>> Jeff
>>
>> On Sat, Jun 9, 2012 at 9:51 PM, Tobias Leich > > wrote:
>>
>> Hi, the tester is still using the old Alien::SDL, this one
>> doesnt build libogg and libvorbis.
>>
>> Jeffrey Palmer > > hat geschrieben:
>>
>> >Hi All,
>> >
>> >I released SDL 2.541_02 today after Blaizer++ merged in his
>> changes that
>> >were accidentally included in 2.538.  The early test reports
>> are in and
>> >we're still having some issues with the SDL::Mixer::MixMusic
>> tests that use
>> >ogg:
>> >
>> >
>> 
>> >http://www.cpantesters.org/cpan/report/5399278a-b262-11e1-bea2-18293af89482
>> >
>> 
>> >http://www.cpantesters.org/cpan/report/e352e802-b262-11e1-85c4-09343af89482
>> >
>> >If anyone has any problems, or if anyone knows what is
>> causing this
>> >problem, please let us know.
>> >
>> >Thanks,
>> >Jeff
>>
>>
>>
>>
>> -- 
>> Jeffrey T. Palmer
>
>
>
>
> -- 
> Jeffrey T. Palmer

Re: SDL 2.541_02 Released

[Jeffrey Palmer]

This problems still occurs occasionally with Alien-SDL 1.434


http://www.cpantesters.org/cpan/report/04921c82-b30c-11e1-9066-3d54fb7543f5

I created an issue about this a while ago:

https://github.com/PerlGameDev/SDL/issues/233

The build option include ogg, but those same tests fail.  Should those
tests pass with those build options?

Jeff

On Sun, Jun 10, 2012 at 1:21 PM, Tobias Leich  wrote:

>  Ya, would be sweet to make another dev release, requiring a newer
> Alien::SDL.
>
> Check t/mixer.t for audio support, its basically just that you try to init
> OGG, and skip if it fails.
>
> Am 10.06.2012 18:03, schrieb Jeffrey Palmer:
>
> So are we ready to bump our Alien::SDL prereq (at least in the dev
> release)?  Also, I'm assuming we should skip these tests if libogg support
> isn't available.  What's the proper way to detect audio format support?
>
>  Jeff
>
> On Sat, Jun 9, 2012 at 9:51 PM, Tobias Leich  wrote:
>
>> Hi, the tester is still using the old Alien::SDL, this one doesnt build
>> libogg and libvorbis.
>>
>> Jeffrey Palmer  hat geschrieben:
>>
>> >Hi All,
>> >
>> >I released SDL 2.541_02 today after Blaizer++ merged in his changes that
>> >were accidentally included in 2.538.  The early test reports are in and
>> >we're still having some issues with the SDL::Mixer::MixMusic tests that
>> use
>> >ogg:
>> >
>> >
>> >
>> http://www.cpantesters.org/cpan/report/5399278a-b262-11e1-bea2-18293af89482
>> >
>> >
>> http://www.cpantesters.org/cpan/report/e352e802-b262-11e1-85c4-09343af89482
>> >
>> >If anyone has any problems, or if anyone knows what is causing this
>> >problem, please let us know.
>> >
>> >Thanks,
>> >Jeff
>>
>
>
>
>  --
> Jeffrey T. Palmer
>
>


-- 
Jeffrey T. Palmer

Re: Transparency?

[Tobias Leich]

These draw_something methods out of the SDLx packages just use blit at
the end anyway.

A tip: dont care about speed right now, just try to get things working.
Optimize at the end.

Cheers

Am 10.06.2012 18:42, schrieb Alex:
> Hi!
>
> When do we use blit and when do we use draw_something? Is blit faster / 
> better?
>
> Best regards,
> Alex
>
> -Ursprüngliche Nachricht-
> Von: Tobias Leich [mailto:em...@froggs.de] 
> Gesendet: Sonntag, 10. Juni 2012 10:47
> An: Jack Maney; sdl-devel@perl.org
> Betreff: AW: Transparency?
>
> Hi, you have to know that draw_rect works differently for your app surface 
> and regular surfaces. If you draw to your app, the pixels just get the value 
> of the color. But if you do this to a regular surface, and blit that to your 
> app surface, the pixels will be blendet...
> So create a new surface, modify that, blit and update.
>
> Cheers
>
> Jack Maney  hat geschrieben:
>
>> Hello,
>>
>> I'm not so terribly new to Perl but very new to SDL.  I was fiddling with 
>> the following "Hello, World!"-ish code in the SDL manual:
>>
>> use strict;
>> use warnings;
>>
>> use SDL;
>> use SDLx::App;
>>
>> my $app = SDLx::App->new( width=> 800, height => 600 );
>>
>> $app->draw_rect([ $app->width / 4, $app->height / 4,
>>  $app->width / 2, $app->height / 2, ],
>>  [ 0, 0, 255, 255] );
>>
>> $app->update();
>>
>> sleep(5);
>>
>> and found that changing the alpha portion of the rectangle color (eg fading 
>> the rectangle out completely via [0,0,255,0]) had no effect on the rendering 
>> of the rectangle.  I did some searching on this and found some 
>> old
>>  
>> questions
>>  from 4+ years ago, but I'm wondering if there is a simple workaround or an 
>> approach that has come about since then.
>>
>> Thank you for your time,
>>
>> Jack
>>
>>
> -
> eMail ist virenfrei.
> Von AVG überprüft - www.avg.de
> Version: 2012.0.2177 / Virendatenbank: 2425/5054 - Ausgabedatum: 07.06.2012 
>

Re: SDL 2.541_02 Released

[Tobias Leich]

Ya, would be sweet to make another dev release, requiring a newer
Alien::SDL.

Check t/mixer.t for audio support, its basically just that you try to
init OGG, and skip if it fails.

Am 10.06.2012 18:03, schrieb Jeffrey Palmer:
> So are we ready to bump our Alien::SDL prereq (at least in the dev
> release)?  Also, I'm assuming we should skip these tests if libogg
> support isn't available.  What's the proper way to detect audio format
> support?
>
> Jeff
>
> On Sat, Jun 9, 2012 at 9:51 PM, Tobias Leich  > wrote:
>
> Hi, the tester is still using the old Alien::SDL, this one doesnt
> build libogg and libvorbis.
>
> Jeffrey Palmer  > hat geschrieben:
>
> >Hi All,
> >
> >I released SDL 2.541_02 today after Blaizer++ merged in his
> changes that
> >were accidentally included in 2.538.  The early test reports are
> in and
> >we're still having some issues with the SDL::Mixer::MixMusic
> tests that use
> >ogg:
> >
> >
> 
> >http://www.cpantesters.org/cpan/report/5399278a-b262-11e1-bea2-18293af89482
> >
> 
> >http://www.cpantesters.org/cpan/report/e352e802-b262-11e1-85c4-09343af89482
> >
> >If anyone has any problems, or if anyone knows what is causing this
> >problem, please let us know.
> >
> >Thanks,
> >Jeff
>
>
>
>
> -- 
> Jeffrey T. Palmer

AW: Transparency?

[Alex]

Hi!

When do we use blit and when do we use draw_something? Is blit faster / better?

Best regards,
Alex

-Ursprüngliche Nachricht-
Von: Tobias Leich [mailto:em...@froggs.de] 
Gesendet: Sonntag, 10. Juni 2012 10:47
An: Jack Maney; sdl-devel@perl.org
Betreff: AW: Transparency?

Hi, you have to know that draw_rect works differently for your app surface and 
regular surfaces. If you draw to your app, the pixels just get the value of the 
color. But if you do this to a regular surface, and blit that to your app 
surface, the pixels will be blendet...
So create a new surface, modify that, blit and update.

Cheers

Jack Maney  hat geschrieben:

>Hello,
>
>I'm not so terribly new to Perl but very new to SDL.  I was fiddling with the 
>following "Hello, World!"-ish code in the SDL manual:
>
>use strict;
>use warnings;
>
>use SDL;
>use SDLx::App;
>
>my $app = SDLx::App->new( width=> 800, height => 600 );
>
>$app->draw_rect([ $app->width / 4, $app->height / 4,
>  $app->width / 2, $app->height / 2, ],
>  [ 0, 0, 255, 255] );
>
>$app->update();
>
>sleep(5);
>
>and found that changing the alpha portion of the rectangle color (eg fading 
>the rectangle out completely via [0,0,255,0]) had no effect on the rendering 
>of the rectangle.  I did some searching on this and found some 
>old
> 
>questions
> from 4+ years ago, but I'm wondering if there is a simple workaround or an 
>approach that has come about since then.
>
>Thank you for your time,
>
>Jack
>
>

-
eMail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 2012.0.2177 / Virendatenbank: 2425/5054 - Ausgabedatum: 07.06.2012 

Re: SDL 2.541_02 Released

[Jeffrey Palmer]

So are we ready to bump our Alien::SDL prereq (at least in the dev
release)?  Also, I'm assuming we should skip these tests if libogg support
isn't available.  What's the proper way to detect audio format support?

Jeff

On Sat, Jun 9, 2012 at 9:51 PM, Tobias Leich  wrote:

> Hi, the tester is still using the old Alien::SDL, this one doesnt build
> libogg and libvorbis.
>
> Jeffrey Palmer  hat geschrieben:
>
> >Hi All,
> >
> >I released SDL 2.541_02 today after Blaizer++ merged in his changes that
> >were accidentally included in 2.538.  The early test reports are in and
> >we're still having some issues with the SDL::Mixer::MixMusic tests that
> use
> >ogg:
> >
> >
> >
> http://www.cpantesters.org/cpan/report/5399278a-b262-11e1-bea2-18293af89482
> >
> >
> http://www.cpantesters.org/cpan/report/e352e802-b262-11e1-85c4-09343af89482
> >
> >If anyone has any problems, or if anyone knows what is causing this
> >problem, please let us know.
> >
> >Thanks,
> >Jeff
>



-- 
Jeffrey T. Palmer

Re: Movement Stuck With Options of Up and Left...

[Jeffrey Palmer]

Hi Jack,

The problem is that an SDL::Rect stores it's x and y coordinates as
integers.  When you subtract a small value from the coordinate the new
coordinate is truncated, which is why you are able to move in negative
directions.  When you add a small value the same thing happens, but the
truncated value is the same as the value you added to, so no movement.  To
work around this, store the coordinates in variables outside of the rect,
add and subtract using these variables, then update the SDL::Rect
coordinates.

Jeff

On Sun, Jun 10, 2012 at 7:50 AM, Jack Maney  wrote:

> Everyone,
>
> First of all, thanks to Tobias Leech for so quickly answering my previous
> question on alpha values.
>
> Now, I'm trying to understand movement.  I managed to hack together a
> simple, choppy, "movement by teleportation" app in which one can use ASDW
> to move a rectangle around in the screen.  However, inspired by the Pong
> code in the SDL manual, I'm trying to recreate this properly by using
> motion handlers.  The resulting code is at http://pastebin.com/mVHANk7T
>
> The strange thing about it is that movement works just fine, but only up
> and to the left (ie via A and W) not to the right or down (ie via D and S).
>  I'm at a bit of a loss as to what's going on...why would a negative
> x-velocity and positive y-velocity be fine, but not a positive x-velocity
> or a negative y-velocity?  I know that the correct velocity values are
> being set (by de-commenting the debugging print statement and running the
> code), so it's not an issue of the wrong velocity values being set...  Is
> there something obvious that I'm missing here?
>
> Thank you for your time,
>
> Jack
>
>


-- 
Jeffrey T. Palmer

Movement Stuck With Options of Up and Left...

[Jack Maney]

Everyone,

First of all, thanks to Tobias Leech for so quickly answering my previous 
question on alpha values.

Now, I'm trying to understand movement.  I managed to hack together a simple, 
choppy, "movement by teleportation" app in which one can use ASDW to move a 
rectangle around in the screen.  However, inspired by the Pong code in the SDL 
manual, I'm trying to recreate this properly by using motion handlers.  The 
resulting code is at http://pastebin.com/mVHANk7T

The strange thing about it is that movement works just fine, but only up and to 
the left (ie via A and W) not to the right or down (ie via D and S).  I'm at a 
bit of a loss as to what's going on...why would a negative x-velocity and 
positive y-velocity be fine, but not a positive x-velocity or a negative 
y-velocity?  I know that the correct velocity values are being set (by 
de-commenting the debugging print statement and running the code), so it's not 
an issue of the wrong velocity values being set...  Is there something obvious 
that I'm missing here?

Thank you for your time,

Jack

AW: Transparency?

[Tobias Leich]

Hi, you have to know that draw_rect works differently for your app surface and 
regular surfaces. If you draw to your app, the pixels just get the value of the 
color. But if you do this to a regular surface, and blit that to your app 
surface, the pixels will be blendet...
So create a new surface, modify that, blit and update.

Cheers

Jack Maney  hat geschrieben:

>Hello,
>
>I'm not so terribly new to Perl but very new to SDL.  I was fiddling with the 
>following "Hello, World!"-ish code in the SDL manual:
>
>use strict;
>use warnings;
>
>use SDL;
>use SDLx::App;
>
>my $app = SDLx::App->new( width=> 800, height => 600 );
>
>$app->draw_rect([ $app->width / 4, $app->height / 4,
>  $app->width / 2, $app->height / 2, ],
>  [ 0, 0, 255, 255] );
>
>$app->update();
>
>sleep(5);
>
>and found that changing the alpha portion of the rectangle color (eg fading 
>the rectangle out completely via [0,0,255,0]) had no effect on the rendering 
>of the rectangle.  I did some searching on this and found some 
>old
> 
>questions
> from 4+ years ago, but I'm wondering if there is a simple workaround or an 
>approach that has come about since then.
>
>Thank you for your time,
>
>Jack
>
>

Transparency?

[Jack Maney]

Hello,

I'm not so terribly new to Perl but very new to SDL.  I was fiddling with the 
following "Hello, World!"-ish code in the SDL manual:

use strict;
use warnings;

use SDL;
use SDLx::App;

my $app = SDLx::App->new( width=> 800, height => 600 );

$app->draw_rect([ $app->width / 4, $app->height / 4,
  $app->width / 2, $app->height / 2, ],
  [ 0, 0, 255, 255] );

$app->update();

sleep(5);

and found that changing the alpha portion of the rectangle color (eg fading the 
rectangle out completely via [0,0,255,0]) had no effect on the rendering of the 
rectangle.  I did some searching on this and found some 
old
 
questions
 from 4+ years ago, but I'm wondering if there is a simple workaround or an 
approach that has come about since then.

Thank you for your time,

Jack