Remarks: Processing Mazes
From Maze
(Difference between revisions)
(More on the second Processing port) | |||
| Line 1: | Line 1: | ||
| − | [Note 9 July, the quality of the prose took a step backward today as some crucial new ideas were introduced.] | + | [Note 9 July, the quality of the prose took a step backward today as some crucial new ideas were introduced. This section is becoming highly visual, more images will be added before Tuesday.] |
The algorithm that defines the 10 PRINT maze exists independently from the Commodore 64 (C64) platform. In fact, the algorithm can be simply executed with a sheet of graph paper, a pen, and a coin to toss. The act of running the algorithm on a number of different platforms reveals what is essential to the algorithm from the specific constraints and affordances of the C64. The concision of 10 PRINT originates from its clever exploitation of the C64, as explained in section ??. For example, the code need not instruct the lines to wrap to the next line when they reach the edge of the screen because it's built into the system. The lines don't need explicit x- and y-coordinates because each character is drawn precisely next to the previous character to form the grid. More subtle defaults of the C64 include the color (light blue on blue) and the speed at which each new section of the maze is added. When 10 PRINT is ported to other platform, as demonstrated in section ??, these features of the C64 must to be defined consciously within the new platform. The precise color, resolution, and speed of the maze are open to new ideas. While many elements of the C64 program can be modified, some are constraints of the system. Primarily, the 40 x 25 character screen that defines the resolution of the grid is fundamental to the hardware architecture and defines the number of units that can comprise the maze. | The algorithm that defines the 10 PRINT maze exists independently from the Commodore 64 (C64) platform. In fact, the algorithm can be simply executed with a sheet of graph paper, a pen, and a coin to toss. The act of running the algorithm on a number of different platforms reveals what is essential to the algorithm from the specific constraints and affordances of the C64. The concision of 10 PRINT originates from its clever exploitation of the C64, as explained in section ??. For example, the code need not instruct the lines to wrap to the next line when they reach the edge of the screen because it's built into the system. The lines don't need explicit x- and y-coordinates because each character is drawn precisely next to the previous character to form the grid. More subtle defaults of the C64 include the color (light blue on blue) and the speed at which each new section of the maze is added. When 10 PRINT is ported to other platform, as demonstrated in section ??, these features of the C64 must to be defined consciously within the new platform. The precise color, resolution, and speed of the maze are open to new ideas. While many elements of the C64 program can be modified, some are constraints of the system. Primarily, the 40 x 25 character screen that defines the resolution of the grid is fundamental to the hardware architecture and defines the number of units that can comprise the maze. | ||
| Line 7: | Line 7: | ||
The first Processing version of 10 PRINT was written to take advantage of the increased resolution of contemporary screens. It does this by making the thickness and ends of the lines into variables that can be changed while the program runs. The lines of the maze can range from 0.5 to 10 pixels wide and the lines can terminate with a rounded or square end. Like 10 PRINT, it maintains the grid of lines at 40 x 25 units, but unlike 10 PRINT it doesn't add each grid unit in sequence from left to right and top to bottom. In the new high-resolution version, the entire maze is refreshed in unison. Without thinking carefully about it, we used the default Processing colors to create white lines and a black background. In hindsight, this imbued the program with a distinct mood from the original lower-contrast blues of the C64. The result is shown in figures ?? to ??. | The first Processing version of 10 PRINT was written to take advantage of the increased resolution of contemporary screens. It does this by making the thickness and ends of the lines into variables that can be changed while the program runs. The lines of the maze can range from 0.5 to 10 pixels wide and the lines can terminate with a rounded or square end. Like 10 PRINT, it maintains the grid of lines at 40 x 25 units, but unlike 10 PRINT it doesn't add each grid unit in sequence from left to right and top to bottom. In the new high-resolution version, the entire maze is refreshed in unison. Without thinking carefully about it, we used the default Processing colors to create white lines and a black background. In hindsight, this imbued the program with a distinct mood from the original lower-contrast blues of the C64. The result is shown in figures ?? to ??. | ||
| − | After writing this first program to focus entirely on the image of the maze, it became clear that watching the maze build one unit at a time on the C64 is a major component of the program. This behavior doesn't naturally work with Processing because the entire screen updates as a whole, rather than character by character. Processing uses a technique called double-buffering. This means the graphics are drawn to an off-screen image buffer stored in RAM. When the image is finished, it's pushed to the computer's screen. For programs that feature animation or interaction, the result is a new image being written and drawn to the screen about sixty times a second. Unlike in BASIC, the lines of Processing program aren't assigned numbers; each line is run in order from top to bottom and according to some higher level rules. This becomes more clear when we look at this program written in Processing by Ben Fry to approximate the behavior of our 10 PRINT program on the C64: | + | While we were making these variations, we took the opportunity to make some additional quick changes to explore the visual aspects of the 10 PRINT maze. [MORE, about weighting the random values, using different symbols ] |
| + | |||
| + | It's important to note that these changes could have been explored directly on the C64, but it was convenient to do to in Processing because Casey was writing this code and he was more fluent with that syntax than with BASIC. The 10 PRINT variations to explore weighting the random value to have a higher percentage of left-leaning lines is: | ||
| + | |||
| + | 10 print | ||
| + | |||
| + | The 10 PRINT variation to show white and black squares in place of diagonal lines is: | ||
| + | |||
| + | 10 print | ||
| + | |||
| + | After writing this first variable program to focus entirely on the image of the maze, it became clear that watching the maze build one unit at a time on the C64 is a major component of the program. This behavior doesn't naturally work with Processing because the entire screen updates as a whole, rather than character by character. Processing uses a technique called double-buffering. This means the graphics are drawn to an off-screen image buffer stored in RAM. When the image is finished, it's pushed to the computer's screen. For programs that feature animation or interaction, the result is a new image being written and drawn to the screen about sixty times a second. Unlike in BASIC, the lines of Processing program aren't assigned numbers; each line is run in order from top to bottom and according to some higher level rules. This becomes more clear when we look at this program written in Processing by Ben Fry to approximate the behavior of our 10 PRINT program on the C64: | ||
int w = 16; | int w = 16; | ||
