Specifications

The game defines a two-dimensional world of pixels, an d the screen at any time shows a region of that world. The
maze world is never f ully constructed in memory; ra ther, it is constructed dynamically as necessary to fill the scr e en.
This facet is usefu l for games in which drawing the entire virtual world at once requires too much memory.
plane 1 of
logical view
plane 0 of
logical view
build buffer
planes shift in
the build buffer
as the logical view
moves within the
maze world
mapped into
build buffer
using maze
coordinates for
mode X planes
logical
view
window
size of
scrolling
portion of
video screen
maze world pixels
(0,0)
(show_x,show_y)
plane 3 of
logical view
plane 2 of
logical view
We use a build buffer to keep the pixel data relevant to the screen organized in a form convenient for moving into video
memory in mode X. However, in order to avoid having to move the data aroun d a lot in the build buff er (or redraw
the whole screen each time we move the logical v iew window by one pixel), we break the maze world into 4x1 pixel
chunk s using the mode X mapping illustrated in the previous section. The address of the logical view window in the
maze world is used to decide where to p lace the image planes within th e build buffer, and moves around within the
build buffer as the logical window moves in the maze world, as shown in the figure be low.
planes 1, 2, and 3
the window for
this address is in plane 0
the window for
this address is in
window
logical view
3210
3210
The mapping that we have described has a subtle d etail: the address range used for the different planes within the
logical view window may not be the same. Consider the case shown above, in wh ic h show x & 3 == 1. As we
move the logical view window ar ound in the maze world, we need to keep ea ch a ddress block at a fixed plane in the
build buffer (again to avoid having to copy data around ). If we were to keep the plan e s in the orde r 0 to 3 and not put
any extra space between them, the image of plane 0 would in this case overlap with th e image of plane 1 in the build
buffer. By reversing the order, we can avoid this problem (alternatively, we could have used a one-b yte buffer zone
between consecutive planes).
The next proble m is mapping the build buffer into the video memory. We use two buffers in video memory and map
into the non-displayed buffer, then change the VGA register to show the new screen. You can read about this double-
buffering technique in the code and see how it works. The complexity with regard to the plane mapping is that w e
must map the build buffer planes, wh ich are defined in terms of the maze world coordinates, into the video planes,
which are defined in terms of the scre e n coordinates. The picture be low illu strates this problem. In general, a cyclic
shift of the planes suffices for the mapping.
0 1 2 3
video screen
memory
build
buffer
video
(a cyclic shift of planes)
3
2
1
3
2
1
00
memory
0 1 2 3
0 1
3210
build buffer layout
window
logical view
32