nanogui: Microwindows for Hercules


Previous by date: 15 Jul 1999 18:25:40 -0000 Re: Microwindows 0.83 released, Matthew Kirkwood
Next by date: 15 Jul 1999 18:25:40 -0000 Re: Microwindows for Hercules, Greg Haerr
Previous in thread: 15 Jul 1999 18:25:40 -0000 Re: Microwindows for Hercules, Greg Haerr
Next in thread: 15 Jul 1999 18:25:40 -0000 Re: Microwindows for Hercules, Greg Haerr

Subject: RE: Microwindows for Hercules
From: Jakob Eriksson ####@####.####
Date: 15 Jul 1999 18:25:40 -0000
Message-Id: <Pine.GSO.3.95.990715200356.6936A-100000@bilbo.mdh.se>

On Thu, 15 Jul 1999, Greg Haerr wrote:

> : I have examples on how to draw fast lines horizontal, vertical and
> : (x1, y1) -> (x2, y2) using Bresenham.
> : These are in a book in asm. so I don't know about their copyright but
> : I think they are intended to be used, ie public domain.
> : Bresenham on Hercules is a little tricky.
> 
> 	No need.  MicroWindows handles the Bresenham algorithm in the mid
> level code in devdraw.c.  It uses successive calls to drawpixel to make it work.
> In this way, people like you and me don't have to rewrite bresenham for every
> card someone wants....

That is fine for normal cards, but since Hercules cards are so ... strange...
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.

If someone wants asm code I can write it down from the book.

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

> : If I don't remember wrong, there are two buffers on a Hercules (2 * 32k mem)
> : so you can even doublebuffer changes. Now that would be cool to work into
> : the driver.
> : If you other people fix it into working order, I can fix double buffering.
> 
> 	Neither nano-X or microwindows require or use double buffering currently, 
> This might be useful when bitblt is implemented though...

I was rather thinking of a solution not visible to above layers, but
maybe that was not a good idea... :-)
(A hack.)

Regards,
Jakob Eriksson



Previous by date: 15 Jul 1999 18:25:40 -0000 Re: Microwindows 0.83 released, Matthew Kirkwood
Next by date: 15 Jul 1999 18:25:40 -0000 Re: Microwindows for Hercules, Greg Haerr
Previous in thread: 15 Jul 1999 18:25:40 -0000 Re: Microwindows for Hercules, Greg Haerr
Next in thread: 15 Jul 1999 18:25:40 -0000 Re: Microwindows for Hercules, Greg Haerr


Powered by ezmlm-browse 0.20.