Specifications

The next question is the size of the build buffer. If we can limit the size of the maze world, we can allocate a build
buffer large enough to hold any logical view window. If the window starts at pixel ( 0,0) in the maze world, plane 3 is
placed at the beginning of th e build buffer. If the window o ccupies the lower right corner of the maze world, plane 0
is placed at the end of the build buffer. Such calculations are not particularly hard.
However, we do not want to restrict the size of the maze world, so we add a level of indirec tion and move the relative
offset of the logica l view window within the build buffer as the logical view shifts within the maze world. The maze
world c an thus be of almost arbitrary size, and is limited on ly by the size of the c oordin ate types (32-b it indices).
build buffer
copies a contiguous
region of memory for
simplicity
(show_x,show_y)
old img3 + address of
(scr_x,scr_y)
new img3 + address of
(scr_x,scr_y)
(show_x,show_y)
before copy
old logical
view window
new logical
view window
old logical
view window
new logical
view window
build buffer
after copy
The img3 and img3 off variables provide the additional level o f indirection . At any point in time, ad ding the address
calculated from the logical view window coordinates (show x,show y) to the img3 pointer produces a pointer to the
start of plane 3 in the build buffer. However, the actual position of that plane in the build buffer may change over time.
Whenever a new logical view win dow setting is requested, the code checks whether all four planes of the new window
fall within the build buffer boundarie s. If they do not, the window is repositioned within the build buffer in order to
make it fit. To minimize copying, the planes o f the new window are centered within the build buffer. The figure at the
bottom of the previous page illustrates the process.
Finally, we add a memory fence to the build buffer to ensure that we didn’t screw up the co pying calcula tions. Read
about it in the cod e.
The Checkpoint
The order presented here is only a suggestion , but we do strongly recomm end that you rea d the code first, that you
tackle the parts one at a time rath er than working on them all a t once, that you commit working versions to your
repository as you get eac h part working, and that you start with the easier parts. You must do all of these things for the
first checkpoint. Other parts of the fina l MP are optional a t the first ch e ckpoint, and will not serve to make up points
for missing requ ired functionality.
Write the vertical line drawing routine in modex.c. Everything but the function body is already in place for you (even
the function header!), and you can lo ok at the horizontal line drawing routine right next to it, so this part should be an