Lab Assignment 2b -- Part 1 Demo due Thursday, Feb. 9
Part 2 Demo due Thursday, Feb. 16
Writeup due Thursday, Feb. 16
CS 5721, Spring Semester, 2006
25 Points
Topic: Interactive Drawing Using SRGP

References:

The SRGP manual - in:
/opt/local/studata/COURSES/cs5721/srgp_sphigs/SRGP_DISTRIB/doc directory
/opt/local/studata/COURSES/cs5721/srgp_sphigs/SRGP_DISTRIB/include/srgp.h
/opt/local/studata/COURSES/cs5721/srgp_sphigs/SRGP_DISTRIB/include/srgppublic.h
Program examples in Chapter 2 of the text.
Part 1:
Your task for this lab is to finish designing and implementing a "drawing" program -- actually a painting program, since no record is kept of the calls to the graphics primitives. Your program will allow the user to interactively draw lines, polygons, ellipses, etc. by using the mouse.

Specifically, you should allow the user to plot "polyPoints": (a sequence of) points (actually small squares -- say 3x3 pixels), polylines, polygons, "upright" rectangles (separately from polygons), and (full) ellipses. There should also be filled versions of polygons, rectangles, and ellipses.

The way the program will work is that the menu of icons (or small drawings) created in Lab 2 will be used to control the program. The user will first click in one of the icon rectangles, which will enable the drawing of that type of primitive. Then the user will click several times in the drawing area to specify the primitive. Finally, to terminate "polyPoints", a polyline, or a polygon, the user can click in the icon area (maybe on the same option being terminated), or click the right mouse button. Rectangles and ellipses could be automatically terminated after two mouse button (down) presses or a mouse button press then a release, which specify the lower left and upper right vertices.

The main interactive program can be similar to the code of Figure 2.21 (page 49) or the do-while loop in the main.c file in the lab1/sample dirctory of the class account. For simplicity, we assume below that only one locator button is used -- button number 0 (or the "left" mouse button), and that we only process button-DOWN events (ignoring "UP" events). Of course your program can use other combinations of events. In Figure 2.21, replace the "switch" on the buttonOfMostRecentTransition with something like:

  if ((locMeasure.buttonChord[LEFT_BUTTON]==DOWN) && 
		     InIconArea(locMeasure.position)) { 
     switch (IconNumber(locMeasure.position)) {
	case 0: DoPoints() ; break;
	case 1: DoPolyLine() ; break;
	case 2: DoPolygon() ; break;
	     .
	     .
	case 7: DoFilledEllipse() ; break;
	case 8: Clear() ; break;
	case 9: quit = TRUE; break;
     }
  }
where InIconArea is a function that returns "true" if
	0 <= locMeasure.position.x <= xIconMax  and  
 yIconMin <= locMeasure.position.y <= yIconMax
It may be convenient to use GEOM_ptInRect(position, rect) or write your own function: InArea(position, rect)
The function IconNumber returns the value of which icon, i, was picked:
	i = 0 ;
	do {
	  i = i + 1 ;
	} while ( yIconBottom[i] > locMeasure.position.y ) ;

or if all icons are the same height:

	i = (NumButtons - 1) - ( locMeasure.position.y / IconHeight );

and DoPoints does something like:
	inputDev = SRGP_waitEvent( INDEFINITE );
	SRGP_getLocator(&locMeasure);
	while (InDrawingArea(locMeasure.position)) {
	    if (locMeasure.buttonChord[LEFT_BUTTON]==DOWN) {
	      DrawPoint(locMeasure.position);
	    }
	    inputDev = SRGP_waitEvent( INDEFINITE );
	    SRGP_getLocator(&locMeasure);
	}
Note that it is usually necessary to do a waitEvent before each getLocator -- in fact you may want to define a new function that just has those two calls in it (i.e. waitEvent, then getLocator -- see Hint 2 below). Note also that the returned value, inputDev, is not used here. It may be necessary to do an SRGP_waitEvent at other appropriate places. There is a sample executable program lab2bsample (actually a copy of lab2sample in the lab2b directory) in the lab2b directory of the class account that has all the functionality required of Part 1 of Lab 2b.

Part 2: Add the following additional features:

  1. Allow the user to select different colors (to change the foreground color). You can either have a permanent color palatte (as in Demo_Paint) or as a pop-up (as in the lab2sample program). For information about color, see the srgp.color file in /opt/local/studata/COURSES/cs5721/info
  2. Have an option that pops up a "Please do not disturb" sign; the sign should disappear when clicked on - as in the Demo_Paint program.
  3. Use rubber-banding when creating rectangles.
  4. Have a "Clear" option that clears the screen (by drawing a big white rectangle over the drawing area).
The sample executable program Demo_Paint (actually a copy of Demo_Paint in the lab2b directory) in the lab2b directory of the class account that has all the functionality required of both Parts 1 and 2 of Lab 2b.

Hints: 1) You probably just want to modify your lab2.c program for this.
2) It may be useful to have a LocButtonDown function that gets and discards events until it encounters a "button-down" event, and then returns the position member of the event measure.

Additional Features (1 pt each):
1) Use rubber-banding when creating line segments for polygons and polylines.
2) Allow the user to have the option of typing "q" or "Q" to quit.
3) Implement text (using SRGP -- easy).
4) Implement separate (unfilled and filled) circle options (by specifying the center and a radius).
5) Show "rubber-ellipses" when creating ellipses (or circles) -- the ellipses themselves should change, not just the extent rectangle.
6) Give feedback ("highlight" or "inverse video" or..) on option picked.
7) Implement drawing commands, colors, etc. as pull-down or pop-up menus.
8) Make the size of the SRGP window a command-line option (or read it in before initializing SRGP). Your buttons/icons should be "scalable" rather than being of a fixed size.
9) Implement Cut, Copy, and Paste of any rectangular region.
10) Implement line width and line style options.
11) Any other features you can think of -- approved by the instructor.

What to turn in:
Turn in the following items from the Computer Science Lab Report Format:
1. (1 point) The Basic Information (your name, class, section, assignment number, and date) can be on a separate cover sheet or as (highlighted) comments at the top of your main program file.
2. (1 point) The Problem Statement is a brief description of The assignment: above. Note: the problem statement can (and should) be in a comment at the top of your main program file.
4. & 5. (4 points) Describe the Variables and Algorithm(s) used in the main program, especially the top-level interaction loop.
9. (1 point each) Any Extra Credit items.
11. (7 points) Include all Program Listings. These listings should show good style, be appropriately commented, have the important parts highlighted, and include handwritten explanations if it helps the reader's understanding of the code.
13. & 14. (12 points) Do demos of your program showing that it displays the correct images and exits correctly.
15. Include a description of any Known Bugs if needed. You may be able to gain back lost points by a careful analysis of what went wrong and possible fixes.
16. This is optional (and no points usually), but it is useful to think about Possible Improvements. Obviously there are many for this program.
17. Comments on the lab assignment are also optional (and again, no points usually), but appreciated!

Important Note: You may discuss algorithms with other students, but the program and lab report should be your own work.


Page URL: http://www.d.umn.edu /~ddunham/cs5721s06/assignments/lab2b/assignment.html
Page Author: Doug Dunham
Last Modified: Thursday, 02-Feb-2006 09:09:12 CST
Comments to: ddunham@d.umn.edu