Subject:
RE: Bogl changes & Nano-X-0.5
From:
Greg Haerr ####@####.####
Date:
18 May 1999 23:18:43 -0000
Message-Id: <01BEA152.4B714FE0.greg@censoft.com>
On Tuesday, May 18, 1999 4:56 PM, Alex Holden ####@####.#### wrote:
> On Tue, 18 May 1999, Greg Haerr wrote:
> > There are considerable changes that need to be made to use unmodified bogl libraries.
> > The first major issue is that all the bogl entry points need to have code added
> > to support drawing in AND, OR and XOR modes, in addition to SET, which is
> > already implemented.
>
> After thinking about this, and looking at the code, isn't the best way to
> do this for the graphics screen to be mirrored in main memory, and do the
> processing on that then copy only the altered areas out to the buffer on
> the graphics card? That way, you aren't shipping large amounts of data
> over a PCI or ISA bus... I seem to recall Allegro had about five different
> ways of dealing with this problem though, so there probably isn't one
> answer which is best for all situations. It doesn't seem that reading from
> the frame buffer, performing an operation on it, and writing it back out
> again is going to be a very good idea, and I couldn't see any obvious way
> to use the hardware capabilities of the graphics card to do it with the
> Linux Framebuffer interface (maybe you can do it with the accelerated ones
> though).
That is precisely my point about the VGA hw registers that do this
operation for you. In the mean time, XOR draw mode is a must for all the demos...
No, it is far too slow to draw everything twice, once in main, then in graphics ram. In
addition, you'd never know what's been modified. However, the bitblt operations you
speak of are solved with a rearchitecture of the driver model I spoke of in an earlier
mail msg. This involved allowing all graphics operations to be performed on a "bitmap",
where the bitmap is either offscreen memory or the graphics memory. Thus,
the low-level draw primitives take a buffer address into account for all their operations,
and record how many bits per planes, etc. This is how Allegro does it. This is
how nanoX should do it.
>
> BTW, I've just switched the newest bogl library in place of the old one.
> Very few changes at all were needed, though I didn't copy the readpixel()
> stuff (as I said above, I don't think reading it from the framebuffer
> itself is the best way to do it anyway) so you can "rub out" the screen by
> waving the mouse over it. The Map program looks good in VGA16 mode, but on
> the NetWinder it's just a mess of random lines (structure alignment
> problems, no doubt).
Please copy the readpixel routine into your new driver. Readpixel is required
for demo.c program to run, as well as the ReadArea api, as well as the cursor drawing.
Greg
>
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
