Movement Stuck With Options of Up and Left...
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
Re: Movement Stuck With Options of Up and Left...
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 jma...@adknowledge.com 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
AW: Transparency?
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 jma...@adknowledge.com 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 oldhttp://www.velocityreviews.com/forums/t906303-problem-with-alphachannel-with-sdl-xxx-blitting.html questionshttp://markmail.org/message/lqtdvmmjmiryumrw#query:+page:1+mid:q63xng5hz7lpcsbl+state:results 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: Transparency?
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 jma...@adknowledge.com 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 oldhttp://www.velocityreviews.com/forums/t906303-problem-with-alphachannel-with-sdl-xxx-blitting.html questionshttp://markmail.org/message/lqtdvmmjmiryumrw#query:+page:1+mid:q63xng5hz7lpcsbl+state:results 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
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 em...@froggs.de 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 em...@froggs.de wrote: Hi, the tester is still using the old Alien::SDL, this one doesnt build libogg and libvorbis. Jeffrey Palmer jeffrey.t.pal...@gmail.com 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
