Summary: Learn how to use the game-math library for translation and animation in two dimensions.
This module is one in a collection of modules designed for teaching GAME2302 Mathematical Applications for Game Development at Austin Community College in Austin, TX.
What you have learned
In the previous module, you learned:
What you will learn
In this module we will put the game-math library to work. I will provide and explain four sample programs. The first program will teach you how to translate a geometric object in two dimensions. The second program will teach you how to accomplish the same thing but in a possibly more efficient manner. The third program will use the library to produce animation in two dimensions.
(A future module will produce translation and animation in three dimensions.)
The fourth program will teach you how to use methods of the game-math library to produce relatively complex drawings.
I recommend that you open another copy of this module in a separate browser window and use the following links to easily find and view the Images and Listings while you are reading about them.
In this module, I will present and explain four programs that use the game-math library named GM2D04 . The purpose of the first program named VectorAdd05 is to use the addVectorToPoint method of the GM2D04.Point class to translate a geometric object from one location in space to a different location in space.
The purpose of the program named VectorAdd05a is to accomplish the same translation operation, but in a possibly more efficient manner.
The purpose of the program named VectorAdd06 is to teach you how to do rudimentary animation using the game-math library.
The purpose of the program named StringArt01 is to teach you how to use methods of the game-math library to produce relatively complex drawings.
All of the programs are interactive in that they provide a GUI that allows the user to modify certain aspects of the behavior of the program.
I will also provide an exercise for you to complete on your own at the end of the module. The exercise will concentrate on the material that you have learned in this module and previous modules.
The game-math library that we are developing in this collection of modules has undergone several updates since its inception in the first module. The version of the library that existed at the end of the previous module was named GM2D04 . No revisions have been made to the library since that module and we won't be making any revisions during this module.
The source code for the library named GM2D04 is provided for your convenience in Listing 17 near the end of the module. Documentation for the library was provided in the earlier module titled GAME 2302-0125: Vector Addition .
The main purpose of this program is to use the addVectorToPoint method of the GM2D04.Point class in the game-math library to translate a geometric object from one location in space to a different location in space. This is illustrated in Image 1 , which shows one hexagon (shown in black) having been translated by 50 units in both the x and y directions and colored red at the new location.
| Image 1: Translation of black hexagon to location of red hexagon. |
|---|
![]() |
Various other game-math library methods are also used
Along the way, the program uses various other methods of the classes in the game-math library named GM2D04 to accomplish its purpose.
The program initially constructs and draws a black hexagon centered on the origin as shown in Image 1 . The six points that define the vertices of the hexagon lie on a circle with a radius of 50 units. The points at the vertices and the lines that connect the points are drawn. In addition, the program causes the hexagon to be translated by 50 units in the positive X direction and 50 units in the positive Y direction. The translated hexagon is drawn in red. The original black hexagon is not erased when the translated version is drawn in red.
A graphical user interface (GUI)
A GUI is provided that allows the user to specify the following items and click a Replot button to cause the drawing to change:
These user-input features are shown at the bottom of Image 1 .
Changing the number of points
Changing the number of points causes the number of vertices that describe the geometric object to change. For a large number of points, the geometric object becomes a circle as shown in Image 2 .
| Image 2: Screen output for geometric object with 50 vertices. |
|---|
![]() |
For only three points, the geometric object would become a triangle. For four points, it would become a rectangle. For two points, it would become a line, etc.
Translation
Changing the components of the displacement vector causes the geometric object to be translated to a different location before being drawn in red. In addition to increasing the number of vertices, Image 2 also shows the result of translating by 30 units along the x-axis and -40 units along the y-axis.
The positive direction for the y-axis is down in the figures in this module. This is the default for Java graphics. I will resolve that issue and cause the positive direction for the y-axis to be up instead of down in a future module.
Checking and un-checking the checkboxes
Image 3 shows the result of un-checking one of the checkboxes to prevent the points that define the vertices from being drawn. In this case, only the lines that connect the vertices were drawn, resulting in the two circles shown.
| Image 3: Screen output without drawing the points at the vertices. |
|---|
![]() |
Similarly, the GUI can be used to cause only the points that define the vertices to be drawn without the connecting lines.
Will explain the code in fragments
I will explain the code in this program in fragments. A complete listing of the program is provided in Listing 18 for your convenience.
Much of the code in this module is very similar to code that I have explained in earlier modules, so I won't bore you by repeating those explanations. Rather, I will concentrate on code that is new and different in this module.
Beginning of the class named GUI
The beginning of the class named GUI is shown in Listing 1 .
| Listing 1: Instance variables in the class named GUI. |
|---|
|
The code in Listing 1 declares a large number of instance variables, initializing some of them. Those variables shouldn't require an explanation beyond the embedded comments. I show them here solely to make it easy for you to refer to them later when I discuss them.
Extends JFrame and implements ActionListener
This class extends the JFrame class and implements the ActionListener interface. As you will see later, implementing the ActionListener interface requires that the class contains a concrete definition of the actionPerformed method. It also makes an object of the GUI class eligible for being registered as a listener object on the Replot button shown in Image 1 .
Abbreviated constructor for the GUI class
An Abbreviated listing of the constructor for the GUI class is shown in Listing 2 . Much of the code was deleted from Listing 2 for brevity. You can view the code that was deleted in Listing 18 .
| Listing 2: Abbreviated constructor for the GUI class. |
|---|
|
Arrays for storage of vertices
The constructor begins by instantiating two array objects that will be used to store references to the GM2D04.Point objects that define the vertices of the geometric object.
Set the coordinate frame
Further down in Listing 2 , the constructor calls the method named setCoordinateFrame to erase the off-screen image, draw orthogonal axes on it, and translate the origin to a new location. The code in the setCoordinateFrame method is straightforward and shouldn't require an explanation beyond the embedded comments. You can view that code in Listing 18 .
The fourth parameter to the setCoordinateFrame method is used to determine whether or not to translate the origin by the amount given by the second and third parameters. If true, the origin is translated. If false, the origin is not translated.
The method named drawOffScreen
After setting the coordinate frame, Listing 2 calls the method named drawOffScreen . I will discuss that method in some detail shortly.
Register an ActionListener object
Next, the code in Listing 2 registers the object of the GUI class as an action listener on the Replot button shown in Image 1 . This causes the method named actionPerformed to be executed whenever the user clicks the Replot button. I will also discuss the actionPerformed method shortly.
Repaint the canvas
Finally, Listing 2 calls the repaint method to repaint the canvas. If you have studied the previous modules in this collection, you should know what this does and an explanation should not be necessary.
Beginning of the drawOffScreen method
Listing 3 shows the beginning of the method named drawOffScreen . The purpose of this method is to create the GM2D04.Point objects that define the vertices of the geometric object and to manipulate those points to produce the desired results.
| Listing 3: Beginning of the drawOffScreen method. |
|---|
|
Erase the image and draw the axes
Listing 3 begins by calling the setCoordinateFrame method to erase the off-screen image and draw orthogonal axes, intersecting at the origin on the erased image. Note however that unlike the call to the setCoordinateFrame method that was made in the constructor in Listing 2 , the call to the method in Listing 3 passes false as the fourth parameter, thereby preventing the location of the origin from being modified.
In other words, in this case, the method is being called simply to erase the off-screen image and to draw axes on the clean off-screen image.
(In hindsight, it may have been better to break this method into two separate methods; one to translate the origin and a second to erase the off-screen image and draw the axes.)
Create the points that define the vertices
Then Listing 3 executes a for loop that instantiates the set of mathematical GM2D04.Point objects that define the vertices of the geometric object and saves references to those objects in the array object that was instantiated in Listing 2 . Note that during the first pass through the constructor and the method named drawOffScreen , the length of the array object and the number of points instantiated are both specified by the initial value (6) of the instance variable named numberPoints (see Listing 1 ) .
Some knowledge of trigonometry is required
I told you in an earlier module "I will assume that you either already have, or can gain the required skills in geometry and trigonometry on your own." I included a module titled GAME 2302-0320 Brief Trigonometry Tutorial in this collection to assist you in that effort.
In order to understand the code in the for loop in Listing 3 , you must have at least a rudimentary knowledge of trigonometry.
For now, suffice it to say that this code will instantiate a set of GM2D04.Point objects equally spaced around the circumference of a circle with a radius of 50 units centered on the origin.
(When rendered on the off-screen image, these units will be translated to pixels.)
For the initial value of six points, the first point will be located at an angle of zero degrees relative to the horizontal, and each of the remaining five points will located on the circumference of the circle at an angle that is an even multiple of 360/6 or 60 degrees.
To draw or not to draw the points
Recall that a point has no width, no height, and no depth and is therefore not visible to the human eye. However, when you call the draw method on an object of the GM2D04.Point class, a small circle is drawn around the location of the point marking that location for human consumption.
An if statement embedded in the for loop in Listing 3 tests the value of the boolean instance variable named drawPoints (see Listing 1 , which initializes the value to true) to determine whether or not to draw the circle marking the location of each point as it is instantiated and saved in the array object. If true , the circle is drawn as shown in Image 1 . If false , the circle is not drawn as shown in Image 3 . As you will see later, the user can modify the value of the variable named drawPoints using one of the checkboxes and the Replot button in Image 1 .
The default drawing color is BLACK. When the points are drawn the first time the drawOffScreen method is called, they will be drawn in BLACK, which is a public static final variable in the Color class.
To draw or not to draw the lines
Listing 4 tests the value of the instance variable named drawLines to determine whether or not to draw lines connecting each of the points. This variable is also initialized to true in Listing 1 , and its value can be modified by the user later using one of the checkboxes and the Replot button shown in Image 1 .
| Listing 4: To draw or not to draw the lines. |
|---|
|
Slightly more complicated
Drawing the lines is only slightly more complicated than drawing the points. A for loop is used in Listing 4 to draw lines connecting successive pairs of points whose references were stored in the array named points in Listing 3 . This takes care of all of the required lines but one. Following the for loop, one additional statement is executed to draw a line connecting the points whose references are stored in the first and the last elements in the array.
(I will show you another way to accomplish this wraparound in the program named StringArt01 later in this module.)
No need to save the GM2D04.Line objects
Note that the GM2D04.Line object that is used to draw each connecting line has no value in this program after the line is drawn on the off-screen image. Therefore, there is no need to consume memory by saving a large number of such objects. A single reference variable of the class GM2D04.Line is used to refer to all the objects of the GM2D04.Line class that are used to draw the connecting lines. As each new object of that class is instantiated, the object previously referred to by the reference variable becomes eligible for garbage collection .
(Go to Google and search for the following keywords to learn more about this topic: baldwin java eligible garbage collection.)
Change the drawing color to RED
After the BLACK geometric object shown in Image 1 has been drawn on the off-screen image, it is time to change the drawing color to RED in preparation for translating the object and drawing the translated version of the object. This is accomplished by the single statement in Listing 5 .
| Listing 5: Change the drawing color to RED. |
|---|
|
Translate the geometric object
That brings us to the most important block of code in the entire program, insofar as achieving the main learning objective of the program is concerned.
| Listing 6: Translate the geometric object. |
|---|
|
Listing 6 uses a call to the addVectorToPoint method of the GM2D04.Point class embedded in a for loop to translate each of the vertices (points) that define the original geometric object to a second set of vertices that define a geometric object having the same shape in a different location.
(The initial vector that was used to translate the points in Listing 6 was instantiated in Listing 1 with values of 50,50. That vector may be modified later using the values in the fields named Vector X and Vector Y in the GUI shown in Image 1 when the user clicks the Replot button.)
The new vertices were saved in a different array object referred to by the reference variable named newPoints . It is important to note that in this case, the original geometric object was not moved. Rather, it was replicated in a new location with the new location being defined by a displacement vector added to the value of each original point.
Make it appear to move
In many cases in game programming, you will want to make it appear that the object has actually moved instead of being replicated. That appearance could be achieved by saving the reference to the new GM2D04.Point object back into the same array, thereby replacing the reference that was previously there. Make no mistake about it, however, when using this approach, the translated geometric object is a different object, defined by a new set of GM2D04.Point objects that define the vertices of the geometric object in the new location.
A different approach
A different approach would be to call the setData method of the GM2D04.Point class to modify the coordinate values stored in the existing object that define the location of the point. In that case, it would not be necessary to instantiate a new object, and I suppose it could be argued that such an approach would actually move each vertex, thereby moving the geometric object. If execution speed is an important factor (particularly in animation code) it would probably be useful to run some benchmarks to determine which approach would be best. (I will show you how to implement this approach in the program named VectorAdd05a later in this module.)
Drawing the points
Once again, an if statement is embedded in the code in Listing 6 to determine whether or not to draw the new points on the off-screen image as the new GM2D04.Point objects are instantiated and saved in the array. If the points are drawn, they will be drawn in RED due to the code in Listing 5 .
Drawing the lines
The code in Listing 7 is essentially the same as the code in Listing 4 . This code tests the variable named drawLines to determine whether or not to draw lines connecting the new points in the current drawing color (RED) .
| Listing 7: Draw the lines if drawLines is true. |
|---|
|
End of the method
Listing 7 also signals the end of the method named drawOffScreen .
The actionPerformed method
As mentioned earlier, the actionPerformed method, shown in Listing 8 , is called to respond to each click on the Replot button shown in Image 1 .
| Listing 8: The actionPerformed method. |
|---|
|
Behavior of the actionPerformed method
Basically this method:
End of the program discussion
That ends the discussion of the program named VectorAdd05 .
I promised you earlier that I would explain a different approach to modifying the vertices of the geometric object in order to translate it. That approach is used in the program named VVectorAdd05a , which you will find in Listing 19 .
The only significant change to this program relative to the program named VectorAdd05 is shown in Listing 9 .
| Listing 9: Abbreviated listing of the drawOffScreen method. |
|---|
|
Compare this code with an earlier listing
You should compare the code in Listing 9 with the code in Listing 6 . The code in Listing 9 does not call the addVectorToPoint method to instantiate a new set of GM2D04.Point objects. Instead, it uses lower-level methods from the game-math library to modify the x and y attribute values that define the locations of the existing GM2D04.Point objects.
As you can see, the code in Listing 9 is somewhat more complex than the code in Listing 6 . However, the code in Listing 9 possibly entails lower overhead at runtime. First, it doesn't call the addVectorToPoint method that hides the programming details behind a single method call. Second, the code in Listing 9 doesn't instantiate new objects of the GM2D04.Point class, as is the case in Listing 6 .
A middle ground
A middle ground that is not illustrated here might be to use a method like the addVectorToPoint method to hide the details, but to have that method change the x and y attribute values in the existing points instead of instantiating new objects. None of the three approaches is either right or wrong. There are pros and cons to all three approaches. This is indicative of the kinds of decisions that must be made by developers who design class libraries containing classes and methods to accomplish common tasks.
End of the program discussion
That ends the discussion of the program named VectorAdd05a .
This is an update to the program named VectorAdd05 . The behavior of this program is similar to the earlier program except that instead of displaying a static view of the translated geometric object when the Replot button is clicked, this program animates the geometric object causing it to move from its original location shown in Image 4 to a new location in 100 incremental steps along a straight line path.
| Image 4: Starting point for the hexagon in VectorAdd06. |
|---|
![]() |
The final position
The final position for the translated hexagon depends on the user input values for the vector. Image 5 shows one possible ending point for the translated hexagon.
| Image 5: Possible ending point for the hexagon in VectorAdd06. |
|---|
![]() |
The animation loop
The animation loop sleeps for ten milliseconds during each of the 100 iterations. Therefore, approximately one second (1000 milliseconds and possibly more) is required for the object to make the trip from its initial location to its new location. Once it reaches the new location, the program is ready for the user to change input values and click the Replot button again.
(Each time you click the Replot button, the object can be seen to move from the initial location, not the current location, to the new location.)
As with the program named VectorAdd05 , this program uses the addVectorToPoint method of the GM2D04.Point class to translate a geometric object from one location in space to a different location in space. In this program, however, the translation is performed in 100 incremental steps to produce an animation. As shown in Image 5 , the animated geometric object is drawn in red to make it visually distinct from the original object. The original object is not erased from the display.
The polygon
The program initially constructs and draws a black polygon in the upper-left corner of the canvas as shown in Image 4 . (The polygon is a hexagon in Image 4 .) The six points that define the vertices of the hexagon lie on a circle with a radius of 50 units. The points at the vertices and the lines that connect the points are drawn initially.
Also as shown in Image 4 , a GUI is provided that allows the user to specify the following items and click a Replot button to cause the animation to begin:
As in the previous program, changing the number of points causes the number of vertices that describe the geometric object to change, allowing you to create triangles, rectangles, pentagons, hexagons, circles, etc.
Changing the components of the displacement vector causes the geometric object to be translated to a different location. Checking and unchecking the checkboxes causes the points and/or the lines to either be drawn or not drawn.
Animation performance
On the computer that I am now using, which is not a new one (September 2012), the animation becomes slightly jerky at about 3500 points when both the points and the lines are drawn.
Will explain in fragments
I will explain this program in fragments and will avoid repeating explanations that I have previously given. A complete listing of this program is provided in Listing 20 near the end of the module.
Much of the code in this program is very similar to code that I explained earlier. The thing that is new about this program is the animation aspect of the program. Therefore, I will concentrate mainly on the animation code in my explanation of the program.
The class named MyCanvas, the update method, and the paint method
Before getting into the details of the program, I want to explain the inner workings of the class named MyCanvas that I defined for this program. This class, which is an inner class of the GUI class, is shown in its entirety in Listing 10 .
| Listing 10: The class named MyCanvas, the update method, and the paint method. |
|---|
|
Different from previous version
If you compare this class with the class named MyCanvas in the earlier program named VectorAdd05 (see Listing 18 ) , you will see that this version of the class is considerably different from the previous version.
The previous version simply overrode the method named paint to cause the off-screen image to be copied to the canvas. That is a perfectly good approach for programs where the image that is displayed on the canvas changes only occasionally. However, that is not a good approach for an animation program where the image displayed on the canvas changes frequently.
Calling the update method
Recall that in Java, when we want to display an image on the computer screen, we don't call the overridden paint method directly. Rather, we call the method named repaint .
Among other tasks, the repaint method acts as a traffic cop to decide which application will be allowed to draw on the screen next, but that isn't the main thrust of our interest here. The main thrust of our interest here is that when we call the repaint method, this eventually results in a call to a method named update . By default, the update method paints a white background on the canvas erasing anything that was previously there. Then the update method calls our overridden paint method to draw whatever it is that we want to draw on the canvas.
Can cause undesirable flashing
Normally this is an adequate approach. However, for an animation program, the repetitive painting of a white background on the canvas can cause an undesirable level of flashing in the visual output of the program. In this case, there is no need to paint a white background on the canvas before copying the off-screen image on the canvas because that image will completely fill the canvas with the new image. Therefore, allowing the canvas to be painted white each time the off-screen image is copied to the canvas is unnecessary and does cause flashing on my computer.
Overriding the update method
Listing 10 overrides the update method to eliminate the painting of a white background on the canvas. In Listing 10 , the update method simply calls the overridden paint method to copy the off-screen image onto the canvas. On my computer, this results in a much more pleasing animation output.
The actionPerformed method
The next code fragment that I will explain is the actionPerformed method, which is called in response to each click on the Replot button shown in Image 4 and Image 5 .
Listing 11 shows an abbreviated listing of the actionPerformed method.
| Listing 11: Abbreviated listing of actionPerformed method. |
|---|
|
Most of the code in this method is the same as code that I explained in conjunction with Listing 8 , so I won't repeat that explanation here.
(I deleted that code for brevity in Listing 11 . You can view the method in its entirety in Listing 20 .)
The code in Listing 11 picks up with a statement that sets the value of an instance variable named animation to true. This variable is used simply to prevent the animation from starting until the first time the user clicks the Replot button.
Spawn an animation thread
This is where this program really departs from the previous programs. Listing 11 instantiates an object of an inner Thread class named Animate and saves that object's reference in a local variable named animate . Then Listing 11 uses that variable to call the start method on the Animate object.
I won't attempt to go into all of the technical details involved in this operation. Suffice it to say that this eventually causes a method named run belonging to the Animate object to be executed.
The Animate class and the run method
The Animate class and the run method begin in Listing 12 .
| Listing 12: The inner Thread class named Animate. |
|---|
|
The run method begins by computing incremental x and y displacement values that will be required to move the geometric object from its initial position as shown in Image 4 to its final position as shown in Image 5 in 100 equal steps.
Do the animated move
Then Listing 13 executes 100 iterations of a for loop to cause the geometric object to actually move through those 100 incremental steps and to be drawn on the screen once during each incremental step.
| Listing 13: Do the animated move. |
|---|
|
During each iteration of the for loop...
During each iteration of the for loop in Listing 13 , an incremental displacement vector is created with X and Y component values that are equal to 1/100 of the user-specified displacement vector multiplied by the loop counter value. The incremental displacement vector is used by the code in the drawOffScreen method to translate the geometric object to a new location on the off-screen image. Then the repaint method is called on the canvas to cause the off-screen image to be copied onto the canvas as described in conjunction with Listing 10 earlier.
(Note that the object is translated from its original location, not its current location, during each iteration of the for loop. A different approach would be to save the current location and translate it from the current location during each iteration of the for loop.)
At the end of each iteration of the for loop, the animation thread sleeps for ten milliseconds before starting the next iteration.
The bottom line is that this code causes the geometric object to move in incremental steps from its initial location to a new location based on a displacement vector specified by the user. In other words, the geometric object reaches its final location in a straight-line animated manner, taking 100 steps to get there.
The drawOffScreen method
The drawOffScreen method that is called by the Animation thread in Listing 13 is very similar to the method having the same name that I explained in conjunction with Listing 3 through Listing 7 . Therefore, I won't repeat that explanation here.
The big difference in the use of that method in the two programs is that in the earlier program, the method was called only once to translate the geometric object according to the values in the displacement vector in one giant step. In this program, the values in the displacement vector are divided by 100 and the drawOffScreen method is called 100 times with ten-millisecond pauses between each call to the method. Each time the drawOffScreen method is called, the geometric object ends up closer to its final position and each of the 100 intermediate positions are displayed on the canvas for ten milliseconds.
End of discussion
That ends the discussion of the program named VectorAdd06 .
You may be old enough to remember when people who liked to do handicraft projects created pictures using strings and nails. If not, I'm sure that if you Google the topic of string art , you will find more about the topic than you ever wanted to know.
This program was inspired by some programs that I saw at the Son of String Art page. I will be the first to admit that the output from this program isn't nearly as elaborate or interesting as the output from some of the projects at that web site. Those programs are truly impressive, particularly considering that they were written using a programming language that was "designed to help young people (ages 8 and up) develop 21st century learning skills. (See About Scratch .)
In future modules, however, I will show you how to improve this string art program including the addition of animated translation and rotation of the string-art images in 3D.
Behavior of the program
This program produces a 2D string art image by drawing lines to connect various points that are equally spaced around the circumference of a circle. At startup, the program constructs and draws a multi-colored hexagon centered on the origin as shown in Image 9 . The six points that define the vertices of the hexagon lie on a circle with a radius of 100 units. The points at the vertices are not drawn, but the lines that connect the vertices are drawn.
A GUI is provided that allows the user to specify the following items and click a Replot button to cause the drawing to change:
As in earlier programs in this module, changing the number of points causes the number of vertices that describe the geometric object to change. Changing the number of loops causes the number of lines that are drawn to connect the vertices to change. For a Loop value of 1, each vertex is connected to the one next to it. For a value of 2, additional lines are drawn connecting every other vertex. For a value of 3, additional lines are drawn connecting every third vertex, etc.
Making the number of points and loops large produces some interesting patterns.
Some output from the program
Before getting into the technical details of the program, I am going to show you some sample screen output from the program. Image 6 shows the result of drawing lines to connect the points in the pattern described above among fifteen points that are equally spaced around the circumference of the circle.
| Image 6: String art with 15 vertices and 7 loops. |
|---|
![]() |
Image 7 shows the result of drawing lines in a more complex pattern among 25 points that are equally spaced around the circumference of the circle.
| Image 7: String art with 25 vertices and 11 loops. |
|---|
![]() |
Image 8 shows the result of drawing lines in an extremely complex pattern among 100 points that are equally spaced around the circumference of the circle.
| Image 8: String art with 100 vertices and 100 loops. |
|---|
![]() |
As you can see, there were so many lines and they were so close together in Image 8 that the visual distinction between lines almost completely disappeared.
Finally, Image 9 shows the program output at startup, with six vertices and one loop.
| Image 9: Output from StringArt01 at startup. |
|---|
![]() |
Will discuss in fragments
As is my custom, I will discuss and explain this program in fragments. Much of the code in this program is very similar to code that I have explained earlier, so I won't repeat those explanations. Rather, I will concentrate on the code that is new and different in this program. A complete listing of the program is provided in Listing 21 near the end of the module.
Most of the code that is new to this program is in the method named drawOffScreen , which begins in Listing 14 .
| Listing 14: Beginning of the drawOffScreen method in StringArt01. |
|---|
|
Even some of the code in the method named drawOffScreen was explained earlier, and that is the case for the code in Listing 14 .
Implement the algorithm that draws the lines
Listing 15 begins the outer loop in a pair of nested loops that implement the algorithm to draw the lines shown in Image 6 through Image 9 .
| Listing 15: Implement the algorithm that draws the lines. |
|---|
|
The algorithm
As I mentioned earlier, the algorithm goes something like the following:
The code in the outer loop that begins in Listing 15 is responsible for identifying the beginning and ending points for the lines that will be drawn during one iteration of the outer loop. Given the above information and the embedded comments in Listing 15 , you should have no difficulty understanding the logic in Listing 15 .
Draw the lines
The inner loop in the pair of nested loops is shown in Listing 16 . This loop constructs a series of GM2D04.Line objects and then causes visual manifestations of those objects to be drawn on the off-screen image.
| Listing 16: Draw the lines. |
|---|
|
Once again, given what you now know, and given the embedded comments in the code, you should have no difficulty understanding the logic of the code. Note in particular the requirement to wrap around when the element number exceeds the length of the array containing references to the GM2D04.Point objects that specify the locations of the vertices of the geometric object.
End of the discussion of StringArt01
That ends the discussion of the program named StringArt01 .. It also ends the discussion of all five of the programs that I promised to explain in this module.
The homework assignment for this module was to study the Kjell tutorial through Chapter 5 - Vector Direction .
The homework assignment for the next module is to study the Kjell tutorial through Chapter 6 - Scaling and Unit Vectors .
In addition to studying the Kjell material, you should read at least the next two modules in this collection and bring your questions about that material to the next classroom session.
Finally, you should have begun studying the physics material at the beginning of the semester and you should continue studying one physics module per week thereafter. You should also feel free to bring your questions about that material to the classroom for discussion.
I encourage you to copy the code from Listing 18 through Listing 21 .Compile the code and execute it in conjunction with the game-math library provided in Listing 17 . Experiment with the code, making changes, and observing the results of your changes. Make certain that you can explain why your changes behave as they do.
In this module, I presented and explained four programs that use the game-math library named GM2D04 . The purpose of the program named VectorAdd05 is to use the addVectorToPoint method of the GM2D04.Point class to translate a geometric object from one location in space to a different location in space.
The purpose of the program named VectorAdd05a is to accomplish the same translation operation, but to do so in a possibly more efficient manner.
The purpose of the program named VectorAdd06 is to teach you how to do rudimentary animation using the game-math library.
The purpose of the program named StringArt01 is to teach you how to use methods of the game-math library to produce relatively complex drawings.
All of the programs are interactive in that they provide a GUI that allows the user to modify certain aspects of the behavior of the program.
In the next module, you will learn how to update the game-math library to support 3D math, how to program the equations for projecting a 3D world onto a 2D plane, and how to add vectors in 3D.
You will also learn about scaling, translation, and rotation of a point in both 2D and 3D, about the rotation equations and how to implement them in both 2D and 3D, and much more.
This section contains a variety of miscellaneous information.
Financial : Although the Connexions site makes it possible for you to download a PDF file for this module at no charge, and also makes it possible for you to purchase a pre-printed version of the PDF file, you should be aware that some of the HTML elements in this module may not translate well into PDF.
I also want you to know that, I receive no financial compensation from the Connexions website even if you purchase the PDF version of the module.
In the past, unknown individuals have copied my modules from cnx.org, converted them to Kindle books, and placed them for sale on Amazon.com showing me as the author. I neither receive compensation for those sales nor do I know who does receive compensation. If you purchase such a book, please be aware that it is a copy of a module that is freely available on cnx.org and that it was made and published without my prior knowledge.
Affiliation : I am a professor of Computer Information Technology at Austin Community College in Austin, TX.
Complete listings of the programs discussed in this module are shown in Listing 17 through Listing 21 below.
| Listing 17: Source code for the game-math library named GM2D04. |
|---|
|
.
| Listing 18: Source code for the sample program named VectorAdd05. |
|---|
|
.
| Listing 19: Source code for the program named VectorAdd05a. |
|---|
|
.
| Listing 20: Source code for the program named VectorAdd06. |
|---|
|
.
| Listing 21: Source code for the program named StringArt01. |
|---|
|
Using Java and the game-math library named GM2D04 , , or using a different programming environment of your choice, write a program that begins with an image showing:
No user input controls other than the button should be visible in your image.
Make each side of the pentagon approximately one-half inch in length as shown in Image 10 .
Each time you click the Replot button, a red pentagon appears on top of the black pentagon and then moves smoothly to a random location somewhere in the image as shown in Image 11 .
If you click the button more than once, the old red pentagon is erased and a new red pentagon appears and moves as described above.
Move the red pentagon in a straight line in approximately 100 incremental steps over a time period of approximately one second.
Cause the program to display your name in some manner.
| Image 10: Screen output from Exercise 1 at startup. |
|---|
![]() |
.
| Image 11: Screen output from Exercise 1 after clicking Replot button. |
|---|
![]() |
-end-