Fast Clear VGA mode 13 screen with 16000 byte loop

Trixter wrote:

> CII wrote:
> > A long time ago, 2600 taught me -and some friends as well- that
> during
> > game programming every cycle counts (if you want to make sharp smooth
> > games anyway). Clearing the bitmap screen is no exception, and
> you'll
> > want to do it as fast as possible.
>
> Actually, you'll want to avoid doing unnecessary full-screen clears.
> :-) Search for "dirty rectangles" and/or "dirty spans" for more
> information on performing differential updates of screen buffers. Why
> spend time clearing the screen if you don't have to?
>

Exactly. But what if you needed to clear it? Or is clearing the screen
just setting it to 0? *sigh*



>
> In other words, make it your goal to write each pixel of an off-screen
> buffer ONLY ONCE (or not at all) before it is displayed. Your time is
> much better spent in this area rather than figuring out the best way to
> clear a screen, as such techniques will help you even with modern
> devices (ie making games for cell phones or other closed/embedded
> devices).

Thank you for your game programming lessons as well. I see you're an
expert!

CII wrote:
> ;------------------------
> ;------------------------ CLR VGA SCREEN
> ;------------------------
> MOV AX,0000
> MOV DI,AX
> MOV CX,8000
> CLD
> P01:
> STOSW
> LOOP P01

Your knowledge of assembly is lacking as you don't know about the REP
prefix. So, rewrite the last three lines from:

P01:
STOSW
LOOP P01

to:

REP STOSW

Secondly, if using a 386 or higher, use doublewords. And there are
other things you can do; here's a better routine:

XOR EAX,EAX ; zeros out EAX without touching flags
; MOV DI,AX Not necessary; DI should be loaded properly before we get
here!
MOV ECX,4000
CLD
REP STOSD

Finally, I am glad that you discovered something for yourself and want
to share, as that is always a good thing. But in the future, you
should clarify that what you're posting is for FYI/informational use...
don't try to make it relevant in 2005 because the usable time for this
information is about 10 years too late. (Disclaimer: I program
entries for programming contests on my 8088/CGA -- but all of the
information I have discovered and all of the techniques I have created
I am going to post on a series of web pages and link to them, not flood
a newsgroup with them.)

CII wrote:
> A long time ago, 2600 taught me -and some friends as well- that
during
> game programming every cycle counts (if you want to make sharp smooth
> games anyway). Clearing the bitmap screen is no exception, and
you'll
> want to do it as fast as possible.

Actually, you'll want to avoid doing unnecessary full-screen clears.
:-) Search for "dirty rectangles" and/or "dirty spans" for more
information on performing differential updates of screen buffers. Why
spend time clearing the screen if you don't have to?

In other words, make it your goal to write each pixel of an off-screen
buffer ONLY ONCE (or not at all) before it is displayed. Your time is
much better spent in this area rather than figuring out the best way to
clear a screen, as such techniques will help you even with modern
devices (ie making games for cell phones or other closed/embedded
devices).

Trixter wrote:

> CII wrote:
> > Exactly. But what if you needed to clear it?
>
> My point is that you should *never* need to clear the screen, other
> than maybe once, as setup for the very first frame. If you're clearing
> the entire screen every frame, you're doing something wrong :-)

Good point Trixter, I agree. Now I'll share this one with you:

A long time ago I "discovered" a way around clearing the entire screen,
which was by using the method you described before. I'd simply mask out
the pixels I'd already drawn (and which had changed) for whatever
character I wanted to clear. I would repeat the process for all the
characters on screen and all I had left was the background in an almost
"clear" mode. I was working 2D games back then with a fixed background.
The gain in performance was enormous as I noticed. That's when I "knew" I
should never have to clear the screen anymore repeatedly, except when some
initializing took place.

After a while I started to work on moving backgrounds and in time the
screen got so crowded with changing visual information, that not long after
I began to realize that my background was in fact behaving *almost* like a
character, a really BIG character.

On scrolling games, in the sense of refreshes my background was behaving
not so differently than "normal" characters because it was changing all the
time, and I realized that "erasing" my characters before updating my
background was kind of extra work.

That's when I found out that I could use my old "clear" routines to change
the background as needed. So now my old "clear" routines weren't simply
just "clearing", but also drawing changing images as well. I modified the
routine a bit and it became extremely useful in drawing characters back on
screen too because of its linear nature. Sometimes, I learned, you will
want to "clear" your screen during refreshes. What had changed was the
concept, the way I thought about "clears" from that point forward. That's
what I meant.

Now, as 3D games came into play, the "clear" procedure became less and less
obvious, because since we're not conceptually dealing with bitmaps anymore
(almost), the process of "clearing" the screen is less and less a
rectangular transfer of a bitmap onto a view.

However, if we were to translate our rectangular coordinates (bitmap) into
polar ones (vector-wise), the story changes radically. What used to be old
and useless "clear" routines can now be modified into very useful routines
that can help me in my games set a world "background" in between
refreshes. This is a method I currently use and it's proven very
efficient.

CII wrote:
> Exactly. But what if you needed to clear it?

My point is that you should *never* need to clear the screen, other
than maybe once, as setup for the very first frame. If you're clearing
the entire screen every frame, you're doing something wrong :-)

CII wrote:
> On scrolling games, in the sense of refreshes my background was
behaving
> not so differently than "normal" characters because it was changing
all the
> time, and I realized that "erasing" my characters before updating my
> background was kind of extra work.

Right, just draw the background over where the characters were before
you blit them in their new position. Of course, a better solution is
to have a virtual buffer larger than the display resolution and just
scroll around that using hardware (or emulation via REP MOVS if using
standard mode 13h or something).

> What used to be old
> and useless "clear" routines can now be modified into very useful
routines
> that can help me in my games set a world "background" in between
> refreshes. This is a method I currently use and it's proven very
> efficient.

I am sure people would rather see those routines instead of a clear :-)
Are there downloadable examples of your work, with or without source?

Trixter wrote:

> CII wrote:
> > On scrolling games, in the sense of refreshes my background was
> behaving
> > not so differently than "normal" characters because it was changing
> all the
> > time, and I realized that "erasing" my characters before updating my
> > background was kind of extra work.
>
> Right, just draw the background over where the characters were before
> you blit them in their new position. Of course, a better solution is
> to have a virtual buffer larger than the display resolution and just
> scroll around that using hardware (or emulation via REP MOVS if using
> standard mode 13h or something).
>

True.


>
> > What used to be old
> > and useless "clear" routines can now be modified into very useful
> routines
> > that can help me in my games set a world "background" in between
> > refreshes. This is a method I currently use and it's proven very
> > efficient.
>
> I am sure people would rather see those routines instead of a clear :-)
> Are there downloadable examples of your work, with or without source?

Unfortunately not yet. Most of my past work is on arcade machines which
were (probably still are) of course proprietary hardware and software. The
work I've done on PC's currently belongs to third parties and at the moment
I'm not at liberty to disclose either algorithms, source or downloadables.
However, since they're my techniques and as far as I understand those can't
be owned or governed other than by the "author", I'm free to pass them
along as I see fit. As soon as I find the time I'll try to set up some
working example with details to share it over. My techniques aren't
groundbreaking or anything of the sort I'm sure, but since they're my
conception for the most part I'm sure they have something at least
particular to contribute.

nokturnal wrote:

> modern games rarely clear the buffer, they either write a texture over it
> (some mottled backdrop for example) or for the ingame loop
> every pixel in the viewport is updated each frame.
>
> graphics applications might get away with dirty rectangles but a 3d
> first person shooter would only benefit if the camera is sitting still - the
> INSTANT
> the camera moves every pixel on the screen will change position.
>
> Clearing the buffer at this stage is a waste of time because every pixel in
> the
> buffer is going to be overwritten anyway.
>
> the buffers you really need to be concentrating on clearing quickly are the
> vertex buffers.

...True, unless of course you use the clear routine to update the frame itself.
You see, to "clear" isn't necessarily to set with 0's or 1's. It can be to set
to anything else.

modern games rarely clear the buffer, they either write a texture over it
(some mottled backdrop for example) or for the ingame loop
every pixel in the viewport is updated each frame.

graphics applications might get away with dirty rectangles but a 3d
first person shooter would only benefit if the camera is sitting still - the
INSTANT
the camera moves every pixel on the screen will change position.

Clearing the buffer at this stage is a waste of time because every pixel in
the
buffer is going to be overwritten anyway.

the buffers you really need to be concentrating on clearing quickly are the
vertex buffers.

modern games rarely clear the buffer, they either write a texture over it
(some mottled backdrop for example) or for the ingame loop
every pixel in the viewport is updated each frame.

graphics applications might get away with dirty rectangles but a 3d
first person shooter would only benefit if the camera is sitting still - the
INSTANT
the camera moves every pixel on the screen will change position.

Clearing the buffer at this stage is a waste of time because every pixel in
the
buffer is going to be overwritten anyway.

the buffers you really need to be concentrating on clearing quickly are the
vertex buffers.