Student: Matt Lee
Assignment: 2
Grader: Damian

************************************************

Bresenham:

program runs, buggy (55):                   55
correct implementation of Bresenham (20):   15
no floats and divides (20):                 5 
extra credit (5):                           5
----------------------------------------------
total (100):                                80

Cohen-Sutherland:

program runs, buggy (55):                   40 
inside case correct (10):                   10 
outside case correct (10):                  10 
one clip correct (10):                      10 
two clips correct (10):                     10 
extra credit (5):                            
----------------------------------------------
total (100):                                80 


Comments:
----------------------------------------------

Bresenham algorithm: 
I looked through your code, and though it produces in most cases the
same lines that our implementation does, you should realize that what
you have is NOT exactly the Bresenham line algorithm. The Bresenham
algorithm requires some kind of error term (the distance from the real
mathematical line and the current pixel center.) Instead your
algorithm maintains a running sum of slope - something that Bresenham
avoids.

In terms of implementation the idea was to avoid floats and divides in
this problem set. I see that you tried to get away with your own
little hacked float representation, and you DID use a divide for
finding the slope.  In the end, the problem has a much simpler
solution: Your inner loop might look something like this (if we were
using straight floats and looking at just the first octant for now):

{
error = error + dy/dx
if (error > 0.5)
   choose NE
   error = error-1
else
   choose E
}

Note however, that this decision process (because it does boil down to
a decision between E and NE) is exacly equivalent to:

{
error = error + 2*dy
if (error > dx)
   choose NE
   error = error - 2*dx
else
   choose E
}

The idea is that we multiply through all the potential floats by 2*dx, and
that should restore them to full integer values. Does that make sense?


CohenSutherland algorithm:
Okay, one point that I don't know if you knew or not, is that Cohen
Sutherland is meant to be a recusive function. I see what you have
done is to simply implement two sequential Cohen Sutherlands --
i.e. you reproduced exactly the same code twice. While this works
correctly, it's hardly efficient code. In fact, it's pretty ugly.

The only other thing is, you forgot to address the case where the
clip-type is set to "clipped". You have "internal" and "external"
working, but clipped lines return a clip-type "internal" as
well. Which it should not.


*************************************************