CSE 142 Homework #4:
Pumpkin CAD

The wizards are so impressed with your first pumpkin design program that they've asked you and your fellow programmers to do an enhanced version, a true Computer-Aided Design (CAD) application.  This time, you can use color and graphics.  The results will be limited only by your imagination.  A selection of the most creative solutions will be exhibited and judged in a special assembly. 

DEADLINES AND DELIVERABLES

When?

What?

Monday, November 13, in lecture

The “planned enhancements” list (if you want feedback on it by Thursday)

Monday, November 13, 10:00pm (electronically)

The starter code, modified only with the “beginning changes”

Wednesday, November 15, in lecture

Three things!  Turn-in receipt (from beginning changes, highlighted as described in the instructions); planned enhancements document (if not turned in Monday); starter code call graph

Sunday, November 19, 10:00pm (electronically)

Final version of the program

Monday, November 20, in lecture

Final receipt and any remaining hardcopy materials, such as the screen snapshot and final report.

 

Summary – Getting started – Files - Sample program – Figuring out the program – Enhancing and completing the program – Minimum requirements – Internal requirements – Features beyond the minimum – Finalizing the project – Hall of Fame – Turn in

One goal of this project is to give you some tools for understanding programs, both your own programs and someone else's. In addition, you will have a chance to see all of the C you have studied so far in action, including arrays and pointers.

We will use a computer graphics package called GP142, which contains primitives for drawing graphic elements and interfaces to enable use of the mouse. Modern programming relies heavily on the use of function libraries; learning to understand and use functions simply by reading about them is an important skill.

A summary of what you have to do for this project follows. All parts are required and will affect your course grade.

  1. Make certain small improvements (“beginning changes”) to the skeleton to show that you understand the original program and GP142.
  2. Analyze the skeleton program and produce a "static call graph."
  3. Write out a “planned enhancements document:” a list of the enhancements you plan to add to the starter code to produce your final version.
  4. Implement and turn in your program
  5. Turn in a “screen shot” of your program in operation, showing off as many of your features as you can in a single picture.
  6. Write a short "final report" describing the outcome of your efforts

Unlike past projects, it will not be necessary for you to make your finished program operate more or less exactly like the demo. We'll encourage creativity, but there will still be specific requirements to fulfill.

GETTING STARTED

Read the documentation about GP142 in the course packet, if you haven't already. Don't expect to understand everything the first time you read it. As you work with the program, it will make more and more sense.

Download and unpack the archive as usual (see below). You will notice that the archive contains files named Gp142.c, Gp142.h, and GP142lib.h. You must not change these files (you won’t be able to turn in modified versions of them). (Macintosh users: you must download the four files below and read and follow the MacIntosh instructions for making a GP142 CodeWarrior 5 project.).  The archive also contains the skeleton or starter .c file (hw4_orig.c).

Programs using GP142 cannot be compiled and linked as simply as the programs we have done up to this point. You cannot run the programs by creating a "default project workspace."  Click on the .dsw file to bring up an already-created project.  If you use the supplied .dsw file exclusively, things will be simpler. If you find the need to create your own workspace, you need to know that it is of type "Win32 application" (not "console" as in previous projects), and you have to include Gp142.c in the project as well as your own main program).  There are MSVC tips that might help if you insist on doing it yourself.

Try building and running the skeleton program.  Compare its behavior to that of the sample executable program.

FILES

Users of MSVC 5 or 6 will need one of the following two items:

·        Self-extracting archive for MSVC 6

·        Self-extracting archive for MSVC 5

Mac, Linux, and all others will need the raw source files:

·        hw4_orig.c

·        gp142.c

·        gp142.h

·        gp142lib.h

There are special instructions for building GP142 programs for Mac and X-Windows users.

THE SAMPLE PROGRAM

First, you should play with the demo (sample executable). When you start the program, you'll see a menu of buttons drawn across the left side of the window, and three blank pumpkins drawn next to them.  At any given time, there is one pumpkin which is the “current pumpkin” which will be operated on. Once you have selected a pumpkin, you can place facial features on it, or do other operations.  Try it out!

FIGURING OUT THE PROGRAM

The skeleton you are given as a starter is called hw4_orig.c  It can do much less than the demo.  Build the project and try to figure out everything it can do, both by playing with it and by looking at the code. 

Here’s one interesting thing about the program: there are functions which draw the pumkins; and there are functions which change how the pumpkin looks (what type of eyes, etc.).  You might expect that the former are called by the latter.  But that’s not the case!  See if you can figure out the control flow.

Two exercises are intended to help you understand the program.

  1. Beginning changes, highlighted.  Modify the starter program so that is behaves just as it did originally, with the following two changes:
    1. There should be working “Square Nose” button, which when clicked, causes a square nose to be placed in the center of the pumpkin.
    2. Make the diameter of the initial pumpkin half of what is was originally.  (Not with a button click; just give it this fixed size initially.)

After making these changes, and no others, turn in the program.  Then, on the turn-in receipt, highlight all the changes that you made.  Use a highlighting pen, or circle the areas modified with a thick, dark, pen mark.

  1. Static call graph.
    . Analyze the skeleton program; read through it carefully, perhaps away from the computer. For each function in the program, you should note what functions it calls and what functions call it. When listing the functions called, include all functions, even library and GP142 functions. Then, draw a "call graph" which shows how all the functions of the program are related. Draw the chart freehand on a large piece of paper, with 'main' at the top. There is no fixed format, but it might look somewhat like the "functional decomposition" chart in the lecture packet (unit L) or a "structure chart" from the textbook (p.113, 303, etc.).  Turn this in on the date given at the top of this document.  Be sure it is labeled with your name, section, and ID. [Note: this static call graph is due after the beginning changes, but actually, you might benefit by doing the static call graph first.]

To make the call graph, you are only asked to look at the starter .c.  You should not look inside the GP142.c file or any other files.

ENHANCING AND COMPLETING THE PROGRAM

After you understand the starter program, the next stage is to plan how you want your final program to look.  You can get ideas from the sample executable.  Also, read below to find out what the minimum requirements are.  Then write an “enhancements document”.  This will a separate piece of paper, with a list of the features you want your program to have.  Your list should not include any of the minimum requirements.  This list should say what you want to do, not how you plan to do it.  That is, it should describe how the program works from the user’s point of view, with absolutely no mention of the programming techniques involved.  [Note: according to the deadlines chart above, you can turn in your enhancements document on Monday if you want TA feedback on it by Thursday.  If you turn it in on Wednesday instead, it will not be late, but you won't get it back before the final project is due.] Instead of having the enhancements report on a separate piece of paper, we may announce a different form of turn in.

The first major programming step to undertake to make the program handle multiple pumpkins.  This will be done by introducing arrays, in many places.  After you see the main idea, modify the program so that there are three pumpkins.  This is very important to get right.  It’s more important at this point than adding fancy facial features, or trying to enlarge, shrink, create, delete, or move pumpkins.

Programs that contain arrays and pointers can often be hard to debug.  The most common source of problems are arrays referenced out of bounds, and pointer that don't point where you think they do.  Being "defensive" in your programming (e.g., checking array subscripts) can help.  There is a tool that can help, too: the MSVC debugger (most C++ environments provide such a facility, too).  With the debugger, you can stop the program in mid-execution to examine the values of variables.  We have some debugger information you can read, and there is also an on-line video tutorial. 

Minimum Requirements for the final program

Be able to decorate (at least) three pumpkins, with at least 3 types each of eyes, noses, and mouths.  The buttons for each type of feature should work. The user has to be able to select between pumpkins, and all three pumpkins must remain visible.  Once a feature is placed on a face, it should remain there until another feature of that type is chosen.  If you do this (and do it following the internal and structural requirements below), you will get most of the points of the assignment.

The facial feature shapes can be anything you like, and we encourage creativity. Explore the functions available in GP142 to get ideas for new shapes to draw. The DrawSmile() function in the skeleton program hints at ways in which several objects can be drawn in one operation to create more complex shapes.

Features Beyond the Minimum

To get full credit, you must add some features beyond the minimum requirements.  These could be ones suggested by the sample executable, such as moving, shrinking, enlarging, creating, deleting pumpkins – or could be other features you invent.  We may give more information later about possible features, and about how far beyond the minimum you need to go to get full credit.

Finalizing the Project

Screenshot.  Once your program is finished, run it as if you were going to demo it to your TA.  Get the screen to show as many interesting features as you can.  Then, take a screen snapshot (screen capture), print this, and turn it in (we may have special instructions about this turn in later).

Although the snapshot you turn in should be of your final program, don’t wait until then to figure out how to do a screen snapshot!  On some computers it might be a little tricky.  So figure out how to do this today; then you’ll be ready when you need it.

Finally, write a short final report with two short sections:

            1. Briefly list the features of your program, as actually implemented.  This might be exactly the same as the planned enhancements.  Be sure to mention any features that would not be obvious to a user running your program for the first time.

            2. Briefly mention any problems you know of: things that don’t work, cases where the program blows up, etc.  This applies to the required features as well as to any additional ones.

This report should be on a separate piece of paper, either word processed or handwritten very legibly.  Be sure your name, section, and ID are on it.

All pages that are turned in with the receipt should be stapled to the back of the receipt.

Internal and structural requirements

You must use arrays to manage the multiple pumpkins.  Even if you figure out a way to avoid using arrays, don't – that would lead to major loss of point.  As always, you must follow previously discussed style guidelines, including no global variables (the temptation to use them in this assignment may become very great!  Resist the temptation.)

This time you have much more freedom about how your program is structured, that is, how it is broken into functions. The skeleton program already has many functions. You can change these any way you like, but... not all ways are equally good, and you might get graded down for poor choices. Likewise, anything new that you add should follow the guidelines for style and structure that we have talked about throughout the course.

Homework #4 Hall of Fame

We will be offering some non-credit incentives for extra work, based purely on the creative aspects of your final program. Can you make your program so fun and exciting that all your non-programmer friends are begging for a copy of it?  Or that the TA gets excited and calls everyone in Sieg Hall to come and take a look?  Programs like this will be nominated for a Hall of Fame and will be shown off during a special program in lecture.

Turn In

When you are finished, use the part B turn-in to give us your modified program. Reminder: You will not be able to turn in the Gp142 files, so don't modify them.

This is not a project that you can begin 48 hours before the deadline and hope to finish satisfactorily on time. Get started now.

And don't forget to have fun!