SDL::Tutorial::Animation man page on Fedora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Fedora logo
[printable version]

SDL::Tutorial::AnimatiUser)Contributed Perl DocumenSDL::Tutorial::Animation(3)

NAME
       SDL::Tutorial::Animation

SYNOPSIS
	       # to read this tutorial
	       $ perldoc SDL::Tutorial::Animation

	       # to create a demo animation program based on this tutorial
	       $ perl -MSDL::Tutorial::Animation=sdl_anim.pl -e 1

ANIMATING A RECTANGLE
       Now that you can display a rectangle on the screen, the next step is to
       animate that rectangle.	As with movies, there's no actual motion.
       Computer animations are just very very fast slideshows.	The hard work
       is creating nearly identical images in every slide (or frame, in
       graphics terms).

       Okay, it's not that difficult.

       There is one small difficulty to address, however.  Once you blit one
       surface onto another, the destination is changed permanently.  There's
       no concept of layers here unless you write it yourself.	If you fail to
       take this into account (and just about everyone does at first), you'll
       end up with blurry graphics moving around on the screen.

       There are two approaches to solve this problem, redrawing the screen on
       every frame and saving and restoring the background for every object
       drawn.

   Redrawing the Screen
       Since you have to draw the screen in the right order once to start with
       it's pretty easy to make this into a loop and redraw things in the
       right order for every frame.  Given a SDL::App object $app, a SDL::Rect
       $rect, and a SDL::Color $color, you only have to create a new SDL::Rect
       $bg, representing the whole of the background surface and a new
       SDL::Color $bg_color, representing the background color.	 You can write
       a "draw_frame()" function as follows:

	       sub draw_frame
	       {
		       my ($app, %args) = @_;

		       $app->fill( $args{ bg }, $args{ bg_color } );
		       $app->fill( $args{rect}, $args{rect_color} );
		       $app->update( $args{bg} );
	       }

       Since you can change the "x" and "y" coordinates of a rect with the
       "x()" and "y()" methods, you can move a rectangle across the screen
       with a loop like this:

	       for my $x (0 .. 640)
	       {
		       $rect->x( $x );
		       draw_frame( $app,
			       bg   => $bg,   bg_color	 => $bg_color,
			       rect => $rect, rect_color => $color,
		       );
	       }

       If $rect's starting y position is 190 and its height and width are 100,
       the rectangle (er, square) will move across the middle of the screen.

       Provided you can keep track of the proper order in which to redraw
       rectangles and provided you don't need the optimal speed necessary
       (since blitting every object takes more work than just blitting the
       portions you need), this works quite well.

   Undrawing the Updated Rectangle
       If you need more speed or want to make a different complexity tradeoff,
       you can take a snapshot of the destination rectangle before you blit
       onto it.	 That way, when you need to redraw, you can blit the old
       snapshot back before blitting to the new position.

       Note:  I have no idea how this will work in the face of alpha blending,
       which, admittedly, I haven't even mentioned yet.	 If you don't know
       what this means, forget it.  If you do know what this means and know
       why I'm waving my hands here, feel free to explain what should and what
       does happen and why.  :)

       With this technique, the frame-drawing subroutine has to be a little
       more complicated.  Instead of the background rect, it needs a rect for
       the previous position.  It also needs to do two updates (or must
       perform some scary math to figure out the rectangle of the correct size
       to "update()".  No thanks!).

	       sub undraw_redraw_rect
	       {
		       my ($app, %args) = @_;

		       $app->fill(   $args{old_rect}, $args{bg_color}	);
		       $app->fill(   $args{rect],     $args{rect_color} );
		       $app->update( $args{old_rect}, $args{rect}	);
	       }

       We'll need to create a new SDL::Rect, $old_rect, that is a duplicate of
       $rect, at the same position at first.  You should already know how to
       do this.

       As before, the loop to call "undraw_redraw_rect()" would look something
       like:

	       for my $x (0 .. 640)
	       {
		       $rect->x( $x );

		       undraw_redraw_rect( $app,
			       rect	  => $rect,  old_rect => $old_rect,
			       rect_color => $color, bg_color => $bgcolor,
		       );

		       $old_rect->x( $x );
	       }

       If you run this code, you'll probably notice that it's tremendously
       faster than the previous version.  It may be too fast, where the
       alternate technique was just fast enough.  There are a couple of good
       ways to set a fixed animation speed regardless of the speed of the
       processor and graphics hardware (provided they're good enough, which is
       increasingly often the case), and we'll get to them soon.

SEE ALSO
       SDL::Tutorial::Drawing
	   basic drawing with SDL Perl

       SDL::Tutorial::Images
	   animating images

AUTHOR
       chromatic, <chromatic@wgz.org>

       Written for and maintained by the Perl SDL project,
       <http://sdl.perl.org/>.

BUGS
       No known bugs.

COPYRIGHT
       Copyright (c) 2003 - 2004, chromatic.  All rights reserved.  This
       module is distributed under the same terms as Perl itself, in the hope
       that it is useful but certainly under no guarantee.

perl v5.14.1			  2011-07-18	   SDL::Tutorial::Animation(3)
[top]

List of man pages available for Fedora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net