🚀 go-pugleaf

> Is it possible to have the upper 320x200 in the tweak 320x400
> panable/flipable while the lower 320x200 do NOTHING?  Or is this
> exactly what the split screen mode Y does?

There was split screen code back about 70 or 80 messages.  

Josh

I don't understand the object of splitting the screen and then flipping
only part of it.  From my understanding page flipping is almost
instantaneous, and splitting the screen in half doesn't sound like it
would make anything happen faster.  Will someone please explain the gain
to be had from using a split screen for animation?

daniel reznick

In article <62430013@acf3.NYU.EDU> reznick@acf3.NYU.EDU (Daniel Reznick) writes:
>I don't understand the object of splitting the screen and then flipping
>only part of it.  From my understanding page flipping is almost
>instantaneous, and splitting the screen in half doesn't sound like it
>would make anything happen faster.  Will someone please explain the gain
>to be had from using a split screen for animation?

Picture Wolf-3D in your mind. At the top of the screen is the animation;
at the bottom is a status area. Now the standard animation cycle is

do {
    draw_a_frame();
    swapbuffers();
    }
while (game_not_done);

With a full screen, you have to draw the animation portion of the screen
AND the status information. This takes time, and since the status info
changes at a much slower rate than the animation, you're doing a lot of
drawing which is unnecessary since you're simply redrawing the exact
same picture over and over again.

Now suppose you split the screen, so that there are two smaller pages
and one static portion which is never flipped. You can write your status
info to the static portion, and change that only when you need to.
Meanwhile the animation continues using the smaller pages, and does so
at a faster pace since there's less to be drawn each frame.

It's a very useful technique - I plan on using it myself.

In article <Bss3pz.KLD@news.cso.uiuc.edu> tmkk@uiuc.edu (Khan) writes:
>With a full screen, you have to draw the animation portion of the screen
>AND the status information. This takes time, and since the status info
>changes at a much slower rate than the animation, you're doing a lot of
>drawing which is unnecessary since you're simply redrawing the exact
>same picture over and over again.

Is there something about the 320x400 mode that forces you to do this?
I don't see any reason why you can't draw your status window on each
of your page flip screens once and then just leave it there undisturbed.
Whatever you left on a page flip screen last time through the loop will
still be there next time, right?

Dave Baggett
dmb@wam.umd.edu

> Is there something about the 320x400 mode that forces you to do this?
> I don't see any reason why you can't draw your status window on each
> of your page flip screens once and then just leave it there undisturbed.
> Whatever you left on a page flip screen last time through the loop will
> still be there next time, right?

Good point, Dave.  You should be able to draw your status window and leave it,
only updating when you need to.  I'm sure this is how Wolf3d did it (which is,
I believe, what the original message was about.).

Josh

In article <1992Aug10.185209.28572@wam.umd.edu> dmb@wam.umd.edu (David M. Baggett) writes:
>In article <Bss3pz.KLD@news.cso.uiuc.edu> tmkk@uiuc.edu (Khan) writes:
>>With a full screen, you have to draw the animation portion of the screen
>>AND the status information. This takes time, and since the status info
>>changes at a much slower rate than the animation, you're doing a lot of
>>drawing which is unnecessary since you're simply redrawing the exact
>>same picture over and over again.
>
>Is there something about the 320x400 mode that forces you to do this?

Not that I know of.

>I don't see any reason why you can't draw your status window on each
>of your page flip screens once and then just leave it there undisturbed.

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. I see your point about not having
to update it every frame; as with everything in programing, it's a
tradeoff. If the status info changes frequently, but not quite as
frequently as the animation rate, you may be better off not having to
perform two buffer writes for each status area update, especially if the
status area is complex. If the status area changes only rarely, then
drawing it twice won't have much of an efct on the overall performance
of the program.

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.