Initial conversion to markdown
This commit is contained in:
parent
a96a114403
commit
5e10794a24
362 changed files with 67353 additions and 0 deletions
96
32-04.md
Normal file
96
32-04.md
Normal file
|
|
@ -0,0 +1,96 @@
|
|||
------------------------ --------------------------------- --------------------
|
||||
[Previous](32-03.html) [Table of Contents](index.html) [Next](32-05.html)
|
||||
------------------------ --------------------------------- --------------------
|
||||
|
||||
The second thing you’ll notice is that exquisite shading effects are
|
||||
possible in 360x480 256-color mode; adjacent lines blend together
|
||||
remarkably smoothly, even with the default palette. The VGA allows you
|
||||
to select your 256 colors from a palette of 256K, so you could, if you
|
||||
wished, set up the colors to produce still finer shading albeit with
|
||||
fewer distinctly different colors available. For more on this and
|
||||
related topics, see the coverage of palette reprogramming that begins in
|
||||
the next chapter.
|
||||
|
||||
The one thing you may not notice right away is just how much detail is
|
||||
visible on the screen, because the blending of colors tends to obscure
|
||||
the superior resolution of this mode. Each of the four rectangles
|
||||
displayed measures 180 pixels horizontally by 240 vertically. Put
|
||||
another way, each *one* of those rectangles has two-thirds as many
|
||||
pixels as the entire mode 13H screen; in all, 360x480 256-color mode has
|
||||
2.7 times as many pixels as mode 13H! As mentioned above, the resolution
|
||||
is unevenly distributed, with vertical resolution matching that of mode
|
||||
12H but horizontal resolution barely exceeding that of mode 13H—but
|
||||
resolution is hot stuff, no matter how it’s laid out, and 360x480
|
||||
256-color mode has the highest 256-color resolution you’re ever likely
|
||||
to see on a standard VGA. (SuperVGAs are quite another matter—but when
|
||||
you *require* a SuperVGA you’re automatically excluding what might be a
|
||||
significant chunk of the market for your code.)
|
||||
|
||||
Now that we’ve seen the wonders of which our new mode is capable, let’s
|
||||
take the time to understand how it works.
|
||||
|
||||
### How 360x480 256-Color Mode Works {#Heading5}
|
||||
|
||||
In describing 360x480 256-color mode, I’m going to assume that you’re
|
||||
familiar with the discussion of 320x400 256-color mode in the last
|
||||
chapter. If not, go back to that chapter and read it; the two modes have
|
||||
a great deal in common, and I’m not going to bore you by repeating
|
||||
myself when the goods are just a few page flips (the paper kind) away.
|
||||
|
||||
360x480 256-color mode is essentially 320x400 256-color mode, but
|
||||
stretched in both dimensions. Let’s look at the vertical stretching
|
||||
first, since that’s the simpler of the two.
|
||||
|
||||
#### 480 Scan Lines per Screen: A Little Slower, But No Big Deal {#Heading6}
|
||||
|
||||
There’s nothing unusual about 480 scan lines; standard modes 11H and 12H
|
||||
support that vertical resolution. The number of scan lines has nothing
|
||||
to do with either the number of colors or the horizontal resolution, so
|
||||
converting 320x400 256mode to 320x480 256-color mode is a simple matter
|
||||
of reprogramming the VGA’s vertical control registers—which control the
|
||||
scan lines displayed, the vertical sync pulse, vertical blanking, and
|
||||
the total number of scan lines—to the 480-scansettings, and setting the
|
||||
polarities of the horizontal and vertical sync pulses to tell the
|
||||
monitor to adjust to a 480-line screen.
|
||||
|
||||
Switching to 480 scan lines has the effect of slowing the screen refresh
|
||||
rate. The VGA always displays at 70 Hz *except* in 480-scan-line modes;
|
||||
there, due to the time required to scan the extra lines, the refresh
|
||||
rate slows to 60 Hz. (VGA monitors always scan at the same rate
|
||||
horizontally; that is, the distance across the screen covered by the
|
||||
electron beam in a given period of time is the same in all modes.
|
||||
Consequently, adding extra lines per frame requires extra time.) 60 Hz
|
||||
isn’t *bad*—that’s the only refresh rate the EGA ever supported, and the
|
||||
EGA was the industry standard in its time—but it does tend to flicker a
|
||||
little more and so is a little harder on the eyes than 70 Hz.
|
||||
|
||||
#### 360 Pixels per Scan Line: No Mean Feat {#Heading7}
|
||||
|
||||
Converting from 320 to 360 pixels per scan line is more difficult than
|
||||
converting from 400 to 480 scan lines per screen. None of the VGA’s
|
||||
graphics modes supports 360 pixels across the screen, or anything like
|
||||
it; the standard choices are 320 and 640 pixels across. However, the VGA
|
||||
*does* support the horizontal resolution we seek—360 pixels—in 40-column
|
||||
*text* mode.
|
||||
|
||||
Unfortunately, the register settings that select those horizontal
|
||||
resolutions aren’t directly transferable to graphics mode. Text modes
|
||||
display 9 dots (the width of one character) for each time information is
|
||||
fetched from display memory, while graphics modes display just 4 or 8
|
||||
dots per display memory fetch. (Although it’s a bit confusing, it’s
|
||||
standard terminology to refer to the interval required for one display
|
||||
memory fetch as a “character,” and I’ll follow that terminology from now
|
||||
on.) Consequently, both modes display either 40 or 80 characters per
|
||||
scan line; the only difference is that text modes display more pixels
|
||||
per character. Given that graphics modes *can’t* display 9 dots per
|
||||
character (there’s only enough information for eight 16pixels or four
|
||||
256-color pixels in each memory fetch, and that’s that), we’d seem to be
|
||||
at an impasse.
|
||||
|
||||
------------------------ --------------------------------- --------------------
|
||||
[Previous](32-03.html) [Table of Contents](index.html) [Next](32-05.html)
|
||||
------------------------ --------------------------------- --------------------
|
||||
|
||||
* * * * *
|
||||
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
Loading…
Reference in a new issue