Fast Clear VGA mode 13 screen with 16000 byte loop

Gerry Quinn wrote:

> In article <42558A57.F163C7A6@laposte.net>, x.yss@laposte.net says...
> > Gerry Quinn wrote:
>
> > > CRect clientRect;
> > > GetClientRect( & clientRect );
> > > GetDC()->FillSolidRect( & clientRect, RGB( 0, 0, 0 ) );
> > >
> > > That will blank the MFC window I'm using, fast enough for most
> > > purposes, and it took seconds to write.
> > >
> > > However, I think Blitz Basic has a 'Cls' keyword which is even more
> > > economical.
> > >
> > > In both cases, one need not waste time on issues that are irrelevant to
> > > programming games nowadays.
>
> > You're missing the point, but in any case I understand your position.
> > However, the irrelevancy of such issues depends on the point of view.
>
> I want to write games that people will play. In 2005, and beyond. How
> is a fast assmbly VGA clear relevant?
>
> - Gerry Quinn

You know that a clear routine isn't necessarily used just for clearing. It's
also a very fast way to set up a background to work upon and also for other
technical tricks that some keep in their toolbox.

If you could improve speed on the games you write by say 30%, wouldn't you use
that speed to make your game smoother to play, or maybe to add more detail or
maybe for some special effect that would make your game more playable, visually
better, more efficient?

If I need to do screen refreshes at a certain frame rate and I will also set my
background with "clear" techniques, that makes whatever clear routine I use
more than relevant, because such a routine will work a number of times per
second, so it has to be very very fast, in fact the fastest possible.
Sometimes a programmer will want to skip video drivers to gain speed thus
performance power, and in that case he/she has no choice but to go down to
hardware bit level programming when all else fails. Most of the time, however,
bit level programming would/could sacrifice "portability" and flexibility, so
what to do?

That's where VGA may step in (not a VGA mode, but what we know about VGA).
Because from what I'm observing, VGA isn't just a "standard" for setting video
modes (note how I quote the word standard), VGA is circuitry. What this means
is that, no matter the game and regardless of the platform, if you're using a
SVGA card and on any SVGA mode you use, VGA circuitry is in fact active
underneath (is supposed to be anyway). That should mean that on that case if
you were to stick to "conventional" VGA programming, which has become a
standard of sorts, and if you were to do so without necessarily disregarding
whatever a certain video driver has to offer, you could then write "portable"
and flexible enough code that should work on virtually any video card as long
as VGA is around and doesn't become just a "simulation" of circuitry. If I can
fast clear my screen using VGA, then that method, if exploited smartly, should
also work on any SVGA mode without any special setting.

Heading my notes with the words "VGA mode 13 screen" may threat to have them
tagged as futile, irrelevant or useless. That's a matter of perception.

There also the case of those who are just beginning, and for one reason or
another they may need to use mode 13 when learning basic principles. Because
mode 13 is "linear" as far as the host cpu is concerned, when programming
directly to video ram 320x200x256 may be used more than one could think
because of the simplicity of X+320*Y.

Gerry Quinn wrote:

> In article <425591EE.B0825DAA@laposte.net>, x.yss@laposte.net says...
>
> > Many haven't realized that no matter what type of video hardware is used, as
> > long as it provides SVGA of some sort, VGA is underneath at the bit level.
> > This I have observed. What this means is that VGA may be more important to
> > games today than one could think. As long as they (video manufacturing
> > companies) remain using the concept of "bit planes" to deliver video images,
> > VGA will be there within. This sole fact can exploited for efficiency, and
> > when I program games I want absolutely all the efficiency I can get, which is
> > in part my reason for reading newsgroups, looking for interesting information
> > I could learn from.
>
> Are you quite sure of that? My guess would be that modern graphics
> board use 32-bit pixel-based colour, and VGA is emulated.
>
> Heck, I'm sure of it - one of the Amiga's big problems c. 1995 was that
> the bit-plane graphics technology was horribly unsuited to the 3D games
> genre starting with DOOM. And PC graphics cards are now built to
> target exactly that genre. As a side effect, there is more than enough
> power for 3D applications.
>
> - Gerry Quinn

When it comes right down to it and once you get to "know" the hardware well enough,
all video modes are emulated (ever wonder why "they" (the industry) tagged EGA
modes "native" modes?). What your video hardware provides is mechanisms for you
to control the most exploitable aspects of video rendering at the hardware level,
as far as I've observed. That means that a video card provides the gear. If you
want a video mode you have to build it yourself, unless you use the famous INT 10
calls (video routines inside the card which someone wrote at the factory) or a
video middleman such as "direct x" or whatever. How do you do it on your own? By
programming that gear to fit your needs. What's the gear? Circuitry.

When you set a VGA mode, you're updating that same circuitry, the one that works
for all modes, for CGA, VGA, Hercules, MCGA, SVGA or what have you. If you're
updating circuits during a VGA mode, such updates, depending on the register
programming, should affect SVGA modes as well, because the tags "VGA, SVGA.." and
so on really mean nothing to the circuitry underneath. They are just simple
denominations by which to understand a certain order of arrangement for the video
circuits to operate.

The facts are that video cards use an internal 32 bit (also probably 64 bit) bus,
that they send video data to a DAC circuit, and that such DAC circuit sends RGB
levels right out the video cable. Regardless of the video card, this seems to hold
true even today. I say that it seems so because the video hardware industry has
remained very elusive when it comes to providing hardware information to whom in my
opinion they should. However, as long as there is video ram access, as long as
there is DAC circuitry and as long as you can control the way that ram access is
performed and the way the video circuitry is updated, I think it would be a logical
and safe bet to assume there will always be an accessible and common way to work in
any video mode at the register level.

In the case of the Amiga c. 1995 If I recall correctly, it really wasn't that bit
plane technology wasn't unsuited for 3D games but that there was an enormous lack
of technical examples and expertise available on bit plane technology for
programmers to use to their advantage. Because after all, 3D games aren't really
3D, we all know that. They're just 2D projections on 2D video screens of 3D ideas.

Until a 3D parallel access video ram bus is designed and built, a technology which
I'm currently working on, the concept of 3D graphics on a flat 2D video screen will
keep video programming at a fashion, at least as far as video registers and methods
are concerned.

To understand what goes on inside a video card when one doesn't have schematics at
hand is usually guess work or reverse engineering. Nevertheless it would make
sense for me if I were manufacturing video hardware to continue designing hardware
using bit planes for video ram access because it would mean faster 32 bit ram
accesses (faster for my circuits). If you use one ram chip (???Mx1bit) per plane
then you're set when it comes to design, because if you use a 32 bit bus you'd be
accessing or refreshing 4 planes (ram banks) on a single clock with the use of a
simple 2 bit counter for a 1 pixel access/bus cycle (32 bits/pixel) (8bitsx4
planes=32bits-planes if you serialize bank access 8x. If in parallel, it could be
analogous to saying "32 bit parallel access on 32 ???Mx1bit ram chips counted 1
time).

The same could work for many different layouts, a 3 bit counter on 8 bit planes for
a 2 pixel access/bus cycle (32 bits/pixel, 64 bit bus) (8bitsx8 planes=64
bits-planes) or maybe even a 4 bit counter on 4 planes for the same 2 pixel
access/bus cycle (32 bits/pixel, 32 bit bus switched 2x) (16bitsx4
planes=64bits-planes).

Gerry Quinn wrote:

> In article <4256E0B9.E0627308@laposte.net>, x.yss@laposte.net says...
> > Gerry Quinn wrote:
>
> > > Are you quite sure of that? My guess would be that modern graphics
> > > board use 32-bit pixel-based colour, and VGA is emulated.
> > >
> > > Heck, I'm sure of it - one of the Amiga's big problems c. 1995 was that
> > > the bit-plane graphics technology was horribly unsuited to the 3D games
> > > genre starting with DOOM. And PC graphics cards are now built to
> > > target exactly that genre. As a side effect, there is more than enough
> > > power for 3D applications.
>
> > In the case of the Amiga c. 1995 If I recall correctly, it really wasn't that bit
> > plane technology wasn't unsuited for 3D games but that there was an enormous lack
> > of technical examples and expertise available on bit plane technology for
> > programmers to use to their advantage. Because after all, 3D games aren't really
> > 3D, we all know that. They're just 2D projections on 2D video screens of 3D ideas.
>
> I don't know enough about hardware to comment about what you say about
> video cards, except that it seems to me to have an air of speculation.
> Besides, clearing a 320x200 screen is not particularly useful - if you
> can show how to clear a normal mode using VGA tricks, it might attract
> more interest.
>
> In the case of the Amiga, though, I am quite certain you are wrong.
> First, the Amiga had excellent programmers who knew the machine inside
> out, and clearly at that time just about all of them would have been in
> the process of migrating to the PC. (True, many would have already
> left, but the survivors would most likely have been the dedicated
> hardware guys!) They would have familiarised themselves with the
> techniques used in DOOM.
>
> 17-Bit software did actually release a DOOM-a-like, whose name I can't
> recall. It was playable, but they had to double up on the pixels, i.e.
> the image was composed of 2x2 squares instead of pixels. A technique I
> only ever saw before on the Spectrum's 'Heavy on the Magick', another
> example of technology being stretched a bit beyond its capacity.
>
> The reason bit-planes are bad for 3D games is not rocket science -
> textured 3D images have effectively to be generated pixel by pixel, and
> each pixel is spread across five or six planes. There's a basic
> inefficiency there no matter how you cut it. Sprite-based games, by
> contrast, can be more efficient on bit-planes, because the sprite can
> be written to 16 or 32 pixels at once on each plane. Thus while the
> Amiga actually performed better than '95 era PCs for sprite-type games,
> it was crippled for DOOM-alikes. (Shaded 3D a la Wolfenstein was okay,
> it's only when you add textures that you have to do it pixel by pixel.)
>
> - Gerry Quinn
>

As you said it, such hardware details "seem to you" to have an air of speculation, so
that remains a personal opinion. I have facts to back up every single technical comment
I've made and they (the comments) can be tested over by the right personnel. Isn't that
a healthy way to gather information, to test facts and premises beyond personal
preferences and doubt?

When you say "if you can show a way to clear a "normal" mode using VGA tricks" I can see
you've missed the point of the posts completely. That is exactly what I've been talking
about in the other posts.

As for the Amiga, I'd like to hear the opinion of actual programmers circa that time that
encountered such problems, to see what they have to say.

You speak technically about the troubles of setting pixels to different planes. I
suggest you do some background research on PC video subsystems today and you'll be
surprised of what you learn. If you'd look at my notes thoroughly it'd become clear that
the technique isn't plane oriented but linear instead, which is what I meant when I
mentioned the factor X+320*Y.

Again, you're missing the point the notes are making, and if they don't seem interesting
to you I can understand it, but nevertheless they have the information they do have and
they do work. Irrelevant to you or not, those notes are news in one way or another,
worth posting for others to see I believe. Call them old, outdated or simply useless.
They're truths about VGA systems and they stand to be tested. If they don't work, then
I'll stand corrected and will admit my errors and try to correct them as I can, probably
even learn from them. If they do work, and that they do, why not let them be? Of
course I could also keep all my findings to myself and not share them with anyone, but
that remains a choice I would have to make as I believe.

It's no secret that technical knowledge on video subsystems is VERY limited as far as
game programming is concerned, and that most game programmers feel comfortable using
video drivers simply because they work fast enough for the application in course. If
efficiency is to be found that way, you will forgive me for dissenting. Whatever little
piece of the puzzle anybody can find, no matter how insignificant it may seem to be, may
one day help us to better understand what the video card industry tries today so hard to
hide. They or someone may one day make public the precise workings of video cards to the
last bit, and that may then prove right or wrong beyond any doubt any "speculation" on
the systems. In the meantime better games can be made by better understanding the
hardware, even if you do not go as deep as into the hardware to make the game. That
statement I'm sure many will find true. I've read it over and over in many different
places.

When a programmer believes that a hardware method is faster than any written code, he is
absolutely correct about it. But when such hardware can't be accessed directly and has
to rely on just that, written code to be used, then all efficiency the hardware can
provide is compromised greatly. My question would then be this one: How fast would a
clearing technique such as the one I presented be against a hardware method accessed
through some video driver?

If you will please give me an example of a video mode you like to use when programming
games.

In article <4256CCBC.8D4875FE@laposte.net>, x.yss@laposte.net says...
> Gerry Quinn wrote:

> > I want to write games that people will play. In 2005, and beyond. How
> > is a fast assmbly VGA clear relevant?
>
> You know that a clear routine isn't necessarily used just for clearing. It's
> also a very fast way to set up a background to work upon and also for other
> technical tricks that some keep in their toolbox.
>
> If you could improve speed on the games you write by say 30%, wouldn't you use
> that speed to make your game smoother to play, or maybe to add more detail or
> maybe for some special effect that would make your game more playable, visually
> better, more efficient?

I'm pretty sure that modern hardware can clear the screen many hundreds
of times a second without any special coding.

I don't think simply blanking the screen is realistically going to be a
problem, given that fading it (which at a minimum requires channel
separation as well as arithmetic) isn't a huge one.

Gerry Quinn
http://bindweed.com

In article <4256E0B9.E0627308@laposte.net>, x.yss@laposte.net says...
> Gerry Quinn wrote:

> > Are you quite sure of that? My guess would be that modern graphics
> > board use 32-bit pixel-based colour, and VGA is emulated.
> >
> > Heck, I'm sure of it - one of the Amiga's big problems c. 1995 was that
> > the bit-plane graphics technology was horribly unsuited to the 3D games
> > genre starting with DOOM. And PC graphics cards are now built to
> > target exactly that genre. As a side effect, there is more than enough
> > power for 3D applications.

> In the case of the Amiga c. 1995 If I recall correctly, it really wasn't that bit
> plane technology wasn't unsuited for 3D games but that there was an enormous lack
> of technical examples and expertise available on bit plane technology for
> programmers to use to their advantage. Because after all, 3D games aren't really
> 3D, we all know that. They're just 2D projections on 2D video screens of 3D ideas.

I don't know enough about hardware to comment about what you say about
video cards, except that it seems to me to have an air of speculation.
Besides, clearing a 320x200 screen is not particularly useful - if you
can show how to clear a normal mode using VGA tricks, it might attract
more interest.

In the case of the Amiga, though, I am quite certain you are wrong.
First, the Amiga had excellent programmers who knew the machine inside
out, and clearly at that time just about all of them would have been in
the process of migrating to the PC. (True, many would have already
left, but the survivors would most likely have been the dedicated
hardware guys!) They would have familiarised themselves with the
techniques used in DOOM.

17-Bit software did actually release a DOOM-a-like, whose name I can't
recall. It was playable, but they had to double up on the pixels, i.e.
the image was composed of 2x2 squares instead of pixels. A technique I
only ever saw before on the Spectrum's 'Heavy on the Magick', another
example of technology being stretched a bit beyond its capacity.

The reason bit-planes are bad for 3D games is not rocket science -
textured 3D images have effectively to be generated pixel by pixel, and
each pixel is spread across five or six planes. There's a basic
inefficiency there no matter how you cut it. Sprite-based games, by
contrast, can be more efficient on bit-planes, because the sprite can
be written to 16 or 32 pixels at once on each plane. Thus while the
Amiga actually performed better than '95 era PCs for sprite-type games,
it was crippled for DOOM-alikes. (Shaded 3D a la Wolfenstein was okay,
it's only when you add textures that you have to do it pixel by pixel.)

- Gerry Quinn

In article <4257978A.AFF722B4@laposte.net>, x.yss@laposte.net says...
> Gerry Quinn wrote:

> As you said it, such hardware details "seem to you" to have an air of speculation, so
> that remains a personal opinion. I have facts to back up every single technical comment
> I've made and they (the comments) can be tested over by the right personnel. Isn't that
> a healthy way to gather information, to test facts and premises beyond personal
> preferences and doubt?

Unless I am misunderstanding you, you assert that modern video cards
have some sort of underlying VGA mode in which your code can be used to
improve efficiency of clearing. Just guessing, not being a hardware
guy, but aren't you trying to clear ordinary RAM, then copy it to the
graphics card? Surely the graphics card has custom hardware along with
software or indeed microcode to perform a clear efficiently on its own
memory? So, what you are doing is a software clear in main memory,
useful at times but largely irrelevant to hardware issues. And
normally, you only do software if you want something more complicated
than the operations video cards provide.

As for your facts, you seem to provide code, but no demo of its
spectacular powers.

> When you say "if you can show a way to clear a "normal" mode using VGA tricks" I can see
> you've missed the point of the posts completely. That is exactly what I've been talking
> about in the other posts.
>
> As for the Amiga, I'd like to hear the opinion of actual programmers circa that time that
> encountered such problems, to see what they have to say.
>
> You speak technically about the troubles of setting pixels to different planes. I
> suggest you do some background research on PC video subsystems today and you'll be
> surprised of what you learn. If you'd look at my notes thoroughly it'd become clear that
> the technique isn't plane oriented but linear instead, which is what I meant when I
> mentioned the factor X+320*Y.

You don't seem to understand why, even if video cards use bit-planes
internally, it doesn't really matter for most if not all purpose,
because if they do, they only use them in situations where dedicated
hardware converts between pixel-based and plane-based on the card so
fast it can be ignored.

And the reason bit-plane graphics are unsuited to textured 3D is simple
logic. Simultaneously working on the same pixel in six planes is slow.

> When a programmer believes that a hardware method is faster than any written code, he is
> absolutely correct about it. But when such hardware can't be accessed directly and has
> to rely on just that, written code to be used, then all efficiency the hardware can
> provide is compromised greatly. My question would then be this one: How fast would a
> clearing technique such as the one I presented be against a hardware method accessed
> through some video driver?

If it isn't faster, why is it relevant?

> If you will please give me an example of a video mode you like to use when programming
> games.

I don't even think in those terms. Normally my games work windowed at
the user's normal resolution, or full-screen in one or more appropriate
standard resolutions. I do insist on 24/32-bit colour internally, but
if the user wants to watch in 16, that's okay with me.

- Gerry Quinn

Gerry Quinn wrote:

> In article <4257978A.AFF722B4@laposte.net>, x.yss@laposte.net says...
> > Gerry Quinn wrote:
>
> > As you said it, such hardware details "seem to you" to have an air of speculation, so
> > that remains a personal opinion. I have facts to back up every single technical comment
> > I've made and they (the comments) can be tested over by the right personnel. Isn't that
> > a healthy way to gather information, to test facts and premises beyond personal
> > preferences and doubt?
>
> Unless I am misunderstanding you, you assert that modern video cards
> have some sort of underlying VGA mode in which your code can be used to
> improve efficiency of clearing.

Not just modern cards, but all VGA compatible cards. The underlying presence of VGA on video
subsystems is no assertion of mine. I can point to many references where this is clearly
stated or at least hinted at (i.e., Wilton, R. (1987), Programming PC & PS/2 Video Subsystems,
Microsoft Press, pages 40-43,86-154). My personal but technically rigorous observations have
convinced me of the same as well. I invite those who are studying video hardware on PC systems
today to look into this fact in detail. Much could still be learned. Even where hardware
clear is involved, the fact that VGA lies underneath in one form or another may mean there's
room for improvement yet today.

Despite the stall that I suspect may befall the video subsystem industry in the near future as
far as radical new improvements and designs go, there appears to be much knowledge to be gained
from better understanding the way video cards really work.

Besides being fun and highly educational, the task may provide future game programmers and
hardware designers with different ideas and maybe even new ways to do things better.



> Just guessing, not being a hardware
> guy, but aren't you trying to clear ordinary RAM, then copy it to the
> graphics card?

Your guess is wrong. You seem to be confused about memory and the way it is handled on VGA
systems.




> Surely the graphics card has custom hardware along with software or indeed microcode to
> perform a clear efficiently on its own
> memory? So, what you are doing is a software clear in main memory,
> useful at times but largely irrelevant to hardware issues. And
> normally, you only do software if you want something more complicated
> than the operations video cards provide.

As you've admitted before, your knowledge of the hardware is very limited and it shows. You
are lacking some very basic principles about the workings of video subsystems. To fully
understand and to be able to properly discuss my notes and their meaning I would first suggest
some introductory material on the subject of PC video subsystems hardware.


>
> As for your facts, you seem to provide code, but no demo of its
> spectacular powers.
>

The "demo" is right inside the code itself. The facts are provided in the registers and the
corresponding bits I mention. Anyone with the time, the desire and the purpose can test the
data for its validity in the comfort of the home or in the privacy of the laboratory. By the
way, Poe has some very interesting essays that deal with the proper literary "application" of
sarcasm.

Thank you very much for your feedback.
It's been a pleasure.

In article <42597CB1.55C003F4@laposte.net>, x.yss@laposte.net says...
> Gerry Quinn wrote:

> > As for your facts, you seem to provide code, but no demo of its
> > spectacular powers.

> The "demo" is right inside the code itself. The facts are provided in the registers and the
> corresponding bits I mention. Anyone with the time, the desire and the purpose can test the
> data for its validity in the comfort of the home or in the privacy of the laboratory. By the
> way, Poe has some very interesting essays that deal with the proper literary "application" of
> sarcasm.

For all the bluster about how you know about hardware (let's assume
that the stuff about 3D, bit-planes and the Amiga is a rare lacuna in
your understanding), a demo or even a benchmark is needed to show your
code has real-world application. I was not being sarcastic here. You
claim your code does great things, but you don't show them in action.

Re-reading the code above, I see I was wrong about you clearing
ordinary RAM, but that makes my subsequent point about the limited
utility of code to clear video RAM even stronger.

- Gerry Quinn

Gerry Quinn wrote:

>
> For all the bluster about how you know about hardware (let's assume
> that the stuff about 3D, bit-planes and the Amiga is a rare lacuna in
> your understanding), a demo or even a benchmark is needed to show your
> code has real-world application. I was not being sarcastic here. You
> claim your code does great things, but you don't show them in action.
>

?
Please forgive me, but where in all the posts have I made any mention of my knowledge about
hardware? The only reference to knowledge of hardware I made was about you, or your lack thereof,
as you yourself admitted. I'm sorry, I meant nothing by it. Did I "claim" anywhere that the code I
presented does "great things"?

I'm sorry Mr. Quinn, but I believe it is no longer necessary to respond to your replies any further
on this particular topic. Thanks again for your time and attention.


>
> Re-reading the code above, I see I was wrong about you clearing
> ordinary RAM, but that makes my subsequent point about the limited
> utility of code to clear video RAM even stronger.
>
> - Gerry Quinn

No comments.

Trixter wrote:

> 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
>



Thank you Trixter. I could also use

XOR AX,AX

instead of

MOV AX,0000

But I've chosen to leave the code as it is for clarity when beginners are
involved.






>
> 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.)

Thank you for the assembly 101 lessons. I can see you're quite an expert!
I'm sorry I've upset you so, Trixter, but I made the sense of the post
clear right from the start. It is the choice of the reader to look into it
or not. I don't think you or anybody have the right to tag information as
"relevant" or not to prevent readers from getting to it, outside of an
opinion. If you feel the information is not relevant, then defend your
arguments with data for everyone to read and learn from and not with
personal statements.

Unless I'm mistaken, the name of this newsgroup is "games development
algorithms". If it is I'm posting to the right place. To assume something
is irrelevant just because you think you know it kind of leaves everyone
else off the picture doesn't it?

You have already shown me your prowess in assembly language. If you have
technical arguments to follow just post them and make a contribution.