In this two-part homework, you will modify and extend a program that displays a simple animation of a bug (the insect kind, not the programming kind) gliding across the screen. In Part B, you will have an opportunity to exercise your creativity and imagination.
In addition to concepts with which you should be comfortable by this point, e.g. variables, conditionals, loops, functions, this homework highlights the following concepts:
In addition to the above key concepts, this homework will give you experience with two common necessities of real-world programming:
Note that you have already done some of the first
already, since functions like prinf and
scanf are part of the C standard I/O library.
In this homework, you will use the GP142 graphics library,
written specifically for use in this course.
As with past homeworks, you have a sample executable program (for Part A) to experiment with. Most of these instructions will not make sense until you have tried it. Spend some time playing with it to figure out what it can do. The final version of your Part A program does not have to behave exactly like the sample executable---it is only provided to give an idea of some things you can do.
In Part A of this two-part homework, you will study the provided code framework carefully and make a minor modification. In Part B, you should start with the program you submit for Part A and further modify it to allow multiple bugs to be on the screen at one time, modifying functions to take arrays as parameters.
To start Part A of this homework, look at the starter C file hw4_orig.c. As provided, the program is not quite complete. One of your first jobs is to get it to compile, then run it and figure out what it does. (There's an important note in using GP142 below about compiling the program.)
Once you have a clear understanding of what the program does, you should study the code to find out how it accomplishes this. For example, make sure to understand how clicking a button actually causes the bug animation to change, tracing control flow carefully.
To help guide the rest of your work on this homework,
make a static call graph showing all the functions called in
hw4_orig.c, starting, of course, with main.
Your static call graph should include GP142 functions that
are called directly by functions in hw4_orig.c, but should
not include other functions inside GP142 that are not
used by the starter program. You must hand in this
static call graph along with your Part A turn-in
receipt.
hint: Start with a big piece of paper. After that, you can begin modifying it and write a copy to turn in on a new page.
In your course packet, see Slide F-43 for an example of the style of call graph you should write. In particular, note the following:
As provided, the hw4_orig.c program displays a single bug that glides across the screen, "wrapping" to the other side of the screen when it reaches the edge. A panel of buttons is visible in the top-left corner of the screen. Most of them work, but the "hopping" button does not.
For Part A, you should modify hw4_orig.c to make the "hopping" and "gliding" buttons work, i.e. so that when the user clicks the "hopping" button, the bug begins to hop (instead of just glide) across the screen, and when the user clicks the "gliding" button, the bug stops hopping and resumes gliding across the screen without moving up or down. (This is exactly the way the sample executable works.) We suggest one simple way to implement hopping in implementation notes below. However, if you prefer, you may make your bug hop using some other algorithm; i.e. your bug does not have to hop exactly like the one in the sample executable, but it should be similar. Whatever method you choose, clicking the "hopping" button should make your bug move up and down as it moves across the screen.
You should not have to add any functions to complete this modification. If you use the method suggested below to make your bug hop, you should be able to complete the modification just by adding several lines of code and changing no more than a few lines elsewhere. You should be able to determine where these changes should be made in the code by studying how it works.
As the bug moves across the screen, its X and Y coordinates (horizontal and vertical, respectively) get updated periodically. The appearance of gliding is accomplished by periodically changing the X coordinate by a small, constant amount.
One way to make the bug hop is by alternating between adding and subtracting some constant amount (an "offset") from the Y coordinate as the bug glides across the screen. By studying hw4_orig.c carefully, you should notice that a count is being maintained of the number of moves taken by the bug as it glides across the screen. You can use this count to decide when to add or subtract the offset as follows:
Remember, you can use the % operator to
determine whether a number is a multiple of another. The
offset and these two constants should be
#define constants in your code.
The method described above is exactly what is implemented in the sample executable, so you can check your program against it. (You might, in fact, notice a few peculiarities. Depending on when you click the "gliding" button, the bug might glide at a height higher or lower than the center line. Depending on when you click the "hopping" button, the bug might hop up or down.)
As always, remember to use good style:
#define constants instead of "magic
numbers"
We encourage you to look at past sample solutions from this quarter as examples of good style.
Once you have completed and submitted code for Part A, continue to improve your program, using what you have learned about programming, to do something interesting. (If you wish, once the sample solution code for Part A is released, you may use that as a starting point for your Part B program.)
The minimal requirement is that your program be able to animate several bugs at the same time. You could do this by randomly having bugs appear from the edge of the window and travel across the screen while other bugs are still on the screen. Another way you could do this is by adding a button to the menu which adds new bugs to the screen when it is clicked.
The key is that the program must be able to keep track of
several bugs at once and the number of bugs has to be
flexible, i.e. you should use arrays to keep track of bug
information (coordinates, color, etc.). Your program should
have a #define constant for the maximum number
of bugs that can be on-screen simultaneously. You will not
receive credit for a program with, for example, three sets
of variables (as opposed to a set of arrays) to keep track
of three (and only three) bugs.
Exactly how you modify your animation is up to you, provided you satisfy the specifications above. The most imaginative programs will be nominated for a Hall of Fame, and, time permitting, a few of them will be demonstrated in lecture.
Here are some possibilities to get your imagination working, but you do not have to choose from this list if you have ideas of your own:
If you decide to use the random number generator in your
Part B program, remember that you will need to
#include the standard library header,
stdlib.h.
You might notice that there are hints in square brackets in the comments included in hw4_orig.c. Some (but not necessarily all) of the places that might require modification are marked with these hint comments.
You will find the GP142 User's Guide (also linked on the main Homework page) useful as a reference as you read and write graphics code in this homework.
If you are using Windows, we strongly advise that you compile and modify the program ONLY via the .dsw file that will be supplied in the self-extracting archive. Here's why: GP142 programs differ from previous projects in some important ways. First, they have multiple .c files (gp142.c in addition to your own). Second, they use a special .h file that must be available to the compiler. Third, they are built as "Windows Applications" rather than "Console Applications." All of this means that you cannot create a "default project workspace" to compile and run your program in. If you double-click on the .dsw file we give you (.dsp for users of some older versions of MSVC), all of these special settings are taken care of.
If you really need to know how to create your own project, look at the MSVC tips page, which is also linked on the course home page.
We recommend that you work on a Windows PC to work on this homework, but the GP142 User's Guide page also includes information for Macintosh and X Windows (UNIX) users.
As always, be sure to read the homework submission guidelines, linked on the course home page in the Announcements section. You will have to submit your work (1) via the web using the page linked below and (2) on paper (a printout of the web turn-in receipt page). reminder: Your Part A paper submission must also include your static call graph.
self-extracting archive for Part A, including starter C file
If any clarifications or changes need to be made for this homework, they will be posted to the cse142-announce email list and linked here.
Save paper: Read documents on the web when you can and, if you print, print two-sided. Remember to reuse or recycle this paper when you're done.
