56 lines
3.2 KiB
Markdown
56 lines
3.2 KiB
Markdown
### Split Screens in Other Modes {#Heading11}
|
|
|
|
So far we've only discussed the split screen in mode 10H. What about
|
|
other modes? Generally, the split screen works in any mode; the basic
|
|
rule is that when a scan line on the screen matches the split screen
|
|
scan line, the internal display memory pointer is reset to zero. I've
|
|
found this to be true even in oddball modes, such as line-doubled CGA
|
|
modes and the 320x200 256-color mode (which is really a 320x400 mode
|
|
with each line repeated. For split-screen purposes, the VGA and EGA seem
|
|
to count purely in scan lines, not in rows or doubled scan lines or the
|
|
like. However, I have run into small anomalies in those modes on clones,
|
|
and I haven't tested all modes (nor, lord knows, all clones!) so be
|
|
careful when using the split screen in modes other than modes 0DH-12H,
|
|
and test your code on a variety of hardware.
|
|
|
|
Come to think of it, I warn you about the hazards of running fancy VGA
|
|
code on clones pretty often, don't I? Ah, well—just one of the hazards
|
|
of the diversity and competition of the PC market! It is a fact of life,
|
|
though—if you're a commercial developer and don't test your video code
|
|
on at least half a dozen VGAs, you're living dangerously.
|
|
|
|
What of the split screen in text mode? It works fine; in fact, it not
|
|
only resets the internal memory pointer to zero, but also resets the
|
|
text scan line counter—which marks which line within the font you're
|
|
on—to zero, so the split screen starts out with a full row of text.
|
|
There's only one trick with text mode: When split screen pel panning
|
|
suppression is on, the pel panning setting is forced to 0 for the rest
|
|
of the frame. Unfortunately, 0 is *not* the "no-panning" setting for
|
|
9-dot-wide text; 8 is. The result is that when you turn on split screen
|
|
pel panning suppression, the text in the split screen won't pan with the
|
|
normal screen, as intended, but will also display the undesirable
|
|
characteristic of moving one pixel to the left. Whether this causes any
|
|
noticeable on-screen effects depends on the text displayed by a
|
|
particular application; for example, there should be no problem if the
|
|
split screen has a border of blanks on the left side.
|
|
|
|
### How Safe? {#Heading12}
|
|
|
|
So, how safe *is* it to use the split screen? My opinion is that it's
|
|
perfectly safe, although I'd welcome input from people with extensive
|
|
split screen experience—and the effects are striking enough that the
|
|
split screen is well worth using in certain applications.
|
|
|
|
I'm a little more leery of horizontal smooth scrolling, with or without
|
|
the split screen. Still, the Wilton book doesn't advise any particular
|
|
caution, and I haven't heard any horror stories from the field lately,
|
|
so the clone manufacturers must finally have gotten it right. (I vividly
|
|
remember some early clones years back that *didn't* quite get it right.)
|
|
So, on balance, I'd say to use horizontal smooth scrolling if you really
|
|
need it; on the other hand, in fast animation you can often get away
|
|
with byte scrolling, which is easier, faster, and safer. (I recently saw
|
|
a game that scrolled as smoothly as you could ever want. It was only by
|
|
stopping it with Ctrl-NumLock that I was able to be sure that it was, in
|
|
fact, byte panning, not pel panning.)
|
|
|
|
In short, use the fancy stuff—but only when you have
|