Animation

Source:    animation.bas,  MyDefs.bi
Program: animation.exe

I/O Files: sphere.bmp

Objective: This example tries to illustrate a number of methods for producing animation on the screen output. In addition, elements of a mouse control interface are outlined that allow the user to exit the program on a mouse click.

To some extent, this is the end point of the ‘get-started’ examples and, in part, references back to the first example ScreenDisplay’. However, this first example only introduced the idea of the various screen modes supported within FreeBasic without really using them in any active way. As this mechanism is fairly important to the objective of this example, some detail is provided, starting with the syntax of SCREENSET

SCREENSET [work_page_number][, visible_page_number]

This command sets the current work and visible pages. Page numbers range from [0..num_pages]. You can use this function to achieve page-flipping or double-buffering. The logic of SCREESET is summarized as:

  • If you omit work_page but not visible_page, only visible page is changed.
  • If you omit visible_page but not work_page, only work page is changed.
  • If you omit both arguments, both work page and visible page are reset to page 0.

There are quite a few graphic screen modes that can be looked up, so the following list only outlines the ones  possibly most used:

Mode

Resolution

Type

Text

Char
Size

Screen Colours

1

320x200

CGA

40X25

8x8

16 background,
1 of four sets foreground

2

640x200

CGA

80x25

8x8

16 colours to 2 attributes

7

320x200

EGA

40x25

8x8

16 colours to 16 attributes

8

640x200

EGA

40x25

8x8

16 colours to 16 attributes

9

640x350

EGA

80x25
 80x43

8x14
8x8

16 colours to 16 attributes

11

640x480

VGA

80x30
 80x60

8x16
8x8

256K colours to 2 attributes

12

640x480

VGA

80x30
 80x60

8x16
8x8

256K colours to 16 attributes

13

320x200

MCGA

40X25

8X8

256K colours to 256 attributes

While the details of this example are annotated within the source code itself, some additional comments might help better understand the objectives of the program. First, there is a basic illustration of how animation can be achieved, second there is an outline of a mouse control interface and finally a basic trace facility, which also allows people to understand how the program works using an increment step approach. For example, this program contains 3 trace statement that are commented out by default:

  • Locate 1, 60: Print "Trace-1 hit KB to continue": Sleep
    When turned on, this statement will stop the program after the sphere is drawn in the screen buffer. Normally, you  will not see this happen at run-time. Having figured out what this piece of code is doing, you can hit the keyboard to step onto the next trace statement.


  • Locate 1, 60: Print "Trace-2 hit KB to continue": Sleep
    At this point, the background of the animation is written to the screen and displayed. The code shows the application of the graphics LINE command. This step is really just an extension of the background, but helps to illustrate how a cosine, or any trigonometric function, can be drawn with the graphics LINE command.


  • Locate 1, 60: Print "Trace-3 hit KB to continue": Sleep
    This step stops at the bottom of the main animation loop. On the first iterating the screen window will go black as the first real screen swap is done at the top of the loop. If you hit the keyboard again, you will see the first frame of the animation. Repeatedly hitting the keyboard will incrementally step you through the animation frame by frame. If you move the mouse within the screen window, while the program waits on the SLEEP statement, the next step will show the updated position of the mouse. If you hold the mouse over the text ‘Mouse Exit’ the program will exit provided you hit the keyboard enough times.

Finally a quick word about trace versus debugging. When writing any program, there are 2 stages to solving errors. The first is syntax errors which will be flagged by the compiler and will need to be corrected before the executable (.exe) program is created.  The second type of error occurs at run-time, so while there are no syntax error, there is some sort of logical error in the program. Often this error is simply that the program does not do what you expected, while still running to completion. However, sometime the error is so severe, the program crashes. While this latter type of error  might need to be ‘debugged’ using more sophisticated methods, the trace approach can be effective and much easy to understand and implement. Using this approach you simply add trace statements, like the ones above, at incremental points in the program until you hit the point of error. So at the point where the last trace statement can be displayed positions you at the point of error, such that you can probably see the mistake and correct the error. Of course, there are dynamic errors, e.g. pointer manipulation, which can still be very difficult to resolve using trace. However, by the time you reach this point of sophistication, you will be way past the need of these examples.