Programming Lab #2

This weekend, I finally looped back and got to the second programming lab. It’s the longest of the labs, and has a couple fairly challenging bits, so it seemed appropriate to wait until I had block of time to dedicate to it.

Part I: Drawing and Animation

The first part of the lab was pretty basic drawing and animation. Lessons in changing shape, color and positioning come together in later examples when we build a simple character out of multiple shapes and the animate it programatically. Anticipating the need for a robot in later examples, I created my character in a function from the start. Not too much to remark on here, so I’ll just link to the examples.

Shape
Swatches
Character
Animation

Part II: Duplicating Examples

Part two was significantly more challenging. We were asked to match four examples of increasing difficulty.

Square Lights

The first example has four squares in a larger square. The square under the mouse is white, white the other three squares are black. I accomplished this by drawing four black squares, and then checking the current mouse position and redrawing a white square on top. Looking back at my code after having completed the who lab, it obvious that this could be accomplished much more efficiently. Maybe I’ll return to it if I get a moment.

Color Swapper

In Color Swapper, we have a red rectangle and a blue rectangle. The red rectangle slowly becomes more and more blue as the blue rectangle becomes increasingly red, and vice versa. The end effect makes it appear that the colors are shifting from side to side.

Programmatically, that’s not too far off, and my solution has a “primary” variable as the red value for one rectangle and the blue for the other. The other color value is set by a “secondary” variable whose value is 255 minus the value of the primary. I add another variable to keep track of the direction we’re currently going in, and then decrement or increment the primary value accordingly. Color Swapper

Racetrack

The Racetrack program produces a box that runs around the edge of a box. This actually struck me as one of the most straightforward of the set. I draw a box, and keep track of the direction in which it is moving, starting with it moving to the right. When I hit the edge of the frame, I change to moving it down, and so on. No collision detection here, I just use the “width” and “height” methods to determine to determine where to change direction. This allows the frame to be resized and the animation to continue functioning. Once again, this could be cleaned up, but in the interest of keeping moving, I left well enough alone on this one. Racetrack

Bounce

To my mind, this was by far the hardest example to approach, but eventually one of the simplest to implement. The example shows a box that begins at the top of the frame, and drops as if pulled by gravity toward the bottom. It bounces back up but, having lost some energy, does not return to its original height. After many bounces, it settles on the bottom of the frame.

I enlisted the help of my seriously math-y wife on this one, and between the two of us we managed to overthink the thing through several greatly overcomplicated versions, never getting it quite right. We set the box to change direction at a “top” and then lowered the “top” on each bounce. This made the box appear to “bounce” between two surfaces. We then tried to ease the top bounce… It was never quite right.

After a break, I decided to readdress the problem in a more realistic manner. I set out thinking I’d have to start from scratch, but we actually had created most of the necessary constructs already. I had a variable for velocity, set to 0 at the beginning of the program. I had a variable (held constant, actually) for acceleration, which set the box in motion to begin with. I had a test to tell if the box was at the bottom of the frame, and was able to change its direction. The only missing component was loss of velocity, which was easily implemented through a poorly-named “drag” constant. I added a quick line to decrement the velocity by that constant on each bounce, and the rest took care of itself. Bounce

Part III: Snowman Scene and Sharing Functions

Having made it through the previous examples, the snowman scene was a nice break. This exercise is basically about abstracting code into functions, calling those functions with arguments, and sharing functions. As a general rule, I attempt to split things into functions, so this wasn’t anything too new.

A couple issues did arise, most notably that the scale() method effected not only size, but positioning. I worked around it for my custom function by internally adjusting the passed X and Y values, and simply adapted the stated X and Y values for my drawn snowmen.

To make things a little more interesting, I made the robot have flashing eyes (timed to alternate each second, by test if a given second was even or odd) and added Clint Beharry’s “Snow” function.

Snowman
My Function
Shared Function

Lab instructions available here.