1. Is your polygon algorithm consistent with respect to screen coordinate issues, and does it produce rectangles that are the correct area? What changes to the algorithm did you have to make in order to make it consistent? You might want to make a simple image to demonstrate the mathematical consistency on your web page.
Yes, our polygons are the correct area, as far as we can tell. They are definitely correct for rectangles, and they seem to be correct for more complex polygons to the best of our ability to determine. They do not match quite perfectly with polygons drawn with drawPolygon, because the latter have lines which are based on the direction in which they are drawn. Our scanline based algorithm does not take into account the ordering of verticies. While the two algorithms do not draw exactly the same polgyon, the difference is in all cases less than a pixel, such that if solid (non alpha-blended) versions are used, it is difficult to tell that there is any discrepancy. To make them more correct, we would have to take into account directionality of each edge, and use a version of Bresenham's algorithm to decide the exact way in which the x-intersect was updated at each step for each edge. It's pretty good, though it doesn't always work perfectly, as you can see from this example (a solid fillPolygon with a shaded drawPolygon over it; the orange is overlap, and the dark red is where the drawPolygon was outside the fillPolygon).
We made our scanline algorithm use drawLineC, which is the version of drawLine that fills in both endpoints it is given. This meant that we needed to subtract one from the endpoint of each line in order to get our polygons to be the correct area. Here is an example of a rectangle with the proper area.
2. How many filled polygons of a reasonable (400 pixels < area < 1000 pixels) size and complexity (5-7 edges) can your algorithm draw in 1 second?
As per Bruce's e-mail, we did our benchmark with triangles instead. Using triangles of arbitrary size, we were able to draw only about 4500 polygons per second (compare to about 500,000 lines per second).
3. How many filled circles of a reasonable size (10 pixels < r < 20 pixels) can your algorithm draw in 1 second?
Our algorithm can draw about 100,000 filled circles per second on average.
4. If you extended this assignment in any way, describe what you did and how you did it. Include pictures, or links to pictures that show what you did.
We wrote an algorithm to do flood fills; this is highly evident in the picture of the Enterprise. The saucer section, which is oriented ellipses, is filled with floodFill. This is because oriented ellipses cannot be filled with a scanline algorithm due to the fact that they are not symmetric accross the y-axis. Here is another example of the flood fill.
We can also do transparency effects with all our primitives; this is also demonstrated on both starships. See the previous lab for a description and further demonstrations.
Also, our algorithm can handle complex polygons, which I don't think was a requirement, but the algorithm we used just did things in a way that handled them automatically. Here is an example.
With respect to the question about how we "modified" the scanline algorithm, it is not really meaningful, as we wrote ours from scratch. We wrote the main body of our algorithm before the lab 3 page was posted, and therefore were working on our own. Consequently, I think we have done things somewhat differently than the code given on the site did them, though I have not examined said code; this is based on listening to the problems other groups were having figuring it out.
Here is the first required image, as specified on the lab page. Verticies as follow:
Once again, here are our starships. They have more filled areas, though to be honest, both made use of scanfill versions of polygons, circles, and ellipses. No floodfill was used in the previous pictures; it did not exist at the time of their creation.
