nanogui: Microwindows for Hercules
Subject:
RE: Microwindows for Hercules
From:
Greg Haerr ####@####.####
Date:
15 Jul 1999 18:38:51 -0000
Message-Id: <01BECEBE.64054E50.greg@censoft.com>
: That is fine for normal cards, but since Hercules cards are so ... strange...
The VGA is *far* stranger, believe me, because of it's requiring more than
64k of video memory...
: the algo is very optimized for the Hercules.
: Example:
: ----
: ----
: ----
: ----
:
: If using writepixel, there need be 16 writes to videomemory.
: When using the native HGC linedraw, there need be only 4 writes to videomem.
:
: BYTE BYTE
: 7654321076543210
: ----
: ----
: ----
: ----
:
: The benefit increases the more horizontal the line is.
:
: Also, the algo. uses an incrementing form of bresenham. Very standard,
: yes. But the incrementing scheme takes into account the bizarre
: HGC memory layout.
: Calculating a byte address and bit offset for a given X, Y is rather
: costly, whatever way you do it.
: But when drawing a line you know a lot of stuff already, so you are
: not solving the problem (X, Y) ---> (byte address, bit offset),
: you are only drawing a line.
Yep, you're right. But currently, very few applications require bresenham,
so it's still in the mid level. Far more often is drawing rectangles, which consist
mostly of horizontal lines. This is the code that *must* be fast. The bresenham code
doesn't have to be fast, since it's rarely called for non-scientic apps (the graphd3d demo
code that I've written for microwindows for instance is too large for ELKS...)
: > The fast line draw that we need is the one that calculates the
: > *bit* starting position in a starting scan line byte, and the end *bit* position.
: > The bits in between the begin and end are then filled with ones. For the bytes
: > inbetween, this is ridculously easy, just set them to 0xff. For the begin and
: > end, use a mask to set those bits...
:
: I am not sure about what you mean here.
: You mean we need an algo that returns BYTEADDRESS, BITSTART and BITEND?
Yes, it's already done in HERC_drawpixel. The HERC_drawhline code
will want to precalc each of those for one line, rather than pixel-by-pixel. Take
a look at the hercules driver, and you'll see what I mean.
: I was rather thinking of a solution not visible to above layers, but
: maybe that was not a good idea... :-)
: (A hack.)
:
Nothing wrong with that, except that the low level code for nano-X
and microwindows is only interfaced (currently by design) thru a very few
entry points:
readpixel
drawpixel
drawhline
drawvline
fillrect
This was purposely designed so that I or someone else could actually
write a working driver for a new card in one evening... We can add speed
stuff later, once we find people who actually use it and want the improvement.
Later, I plan on adding a fast text out primitive for Al's work on scrolling
text for ELKS.
Greg
: Regards,
: Jakob Eriksson
:
:
