🚀 go-pugleaf

In article <BstLnJ.Lv6@news.cso.uiuc.edu> tmkk@uiuc.edu (Khan) writes:
>There's no way I know to draw to both pages at once. What you have to do
>is draw your status info to one page and then draw it again to the
>other. This takes twice as long to do.

OK, now I see what you were getting at.  You are doing twice as much
work to update score counters and any other status information because
this "static" stuff needs to be drawn to both (all) page flip screens
at the "same time."  Another complexity of course is that you don't
*want* to draw on all the page flip screens at once, since one of them
will be visible at any given time.  (And drawing to a visible page
produces flicker.)  You need to update your status information on all the
nonvisible page flip screens and then save the changes so you can apply
them to the currently visible screen once it's no longer visible.

But this is just a price to be paid for page flipping -- I don't see
how a split screen would eliminate this problem either.  If you make
the status display half of the split screen a static image (i.e., not
page flipped) then you've got a flicker problem.  If you make it page
flipped, then you're back to the same problem discussed above: you need
to "remember" areas of the window you've changed and apply those
changes to each page flip screen as it becomes nonvisible.  On the
Atari, at least, you *must* page flip; if you don't the results are
absolutely intolerable.  Perhaps multisync monitors or the VGA hardware
itself makes the flicker less obvious on the PC?  (My impression is
that this is so.)

So I guess I'm still curious what the advantage is to the split screen
mode.  One might be that you could use hardware panning on just one
half of the split screen (instead of the whole screen).  So you could
have hardware scrolling *and* a status window, without having to resort
to drawing the status window as though it were a sprite (i.e, every
frame) like Keen 4 through 6 do.

>BTW, I gather that some games do use this technique. There was an issue
>of GameBytes which had a screen shot of some game (might even have been
>Wolf, I can't remember now). The upper portion of the screen showed the
>normal stuff, but the bottom of the screen was garbage. The caption to
>the screen shot apologized for the incomplete picture, saying that the
>split-screen mode used by the program was incompatible with their screen
>capture program.

This could also be caused by a mid-screen palette change.  The screen
capture program would have the data for the bottom half (or third, or
whatever) but not the correct palette, so it would look like garbage.
Neil Forsyth pointed out to me that Lemmings changes the palette at the
top of the icon box -- you can see a flickery line if you look
closely.  A mid-screen palette interrupt has definite (and obvious)
advantages.

Dave Baggett
dmb@wam.umd.edu