bwGraphics Library

Thu, 28 Aug 1997 23:53:10 +0800

This is primarily directed towards Orlando Llanes, but Im sending it via
this list because I would like some input from other people. If anybody
would like the -current- source code, please mail me. I will attach it as a
ZIP (~80KB). NOTE: As I meantioned to Orlando, the source will NOT compile
with the latest version of GPC - but it will compile with the NEXT update
(whenever that is released!)

At 16:58 27/08/97 -0400, you wrote:
>> (VESA.PAS) is included, but completely OLD and NON WORKING!
>  Using Linear Frame Buffers? Or using bank switching? I was thinking of

It WAS working with BOTH. I used the protected mode bank swithing (VBE2),
if needed. I think that code is still in VESA.PAS. I also had VBE2 linear
frame buffer modes working.

>page, then it allocates a new page. There's something I'm curious about,
>does your lib use a loadable device driver? I ask because I saw VGA.DRV If
>it is, it may be a bad idea to use one because you're prolly better off
>using objects.

I have done it so that I have the best of both worlds! The VGA.DRV is in
fact a loadable device driver (DXE) HOWEVER if you look at VGA.PAS (Source
of VGA.DRV) you will see that it mostly a heap of communication routines
using an INGENIOUS scheme developed by me (as fas as I know)! Below is my
first attempt at explaining it:

The device driver loads as a record (pre-initialised) which is defined in
bwGLOBAL.PAS as "bwTGraphDriver". This record defines pointers to two
routines - "ComHandler" and "ComRequest". ANYTHING and EVERYTHING (except
drawing to the screen at this stage) is done using these two routines.
Below is a small diagram which shows how it all works:

       MAIN PROGRAM                      DRIVER

       ComRequest -------------------> ComHandler
       ComHandler <------------------- ComRequest

To communicate with the graphics driver, the MAIN PROGRAM calls
"ComRequest(FunctionNr)" which infact points at the "ComHandler" on the
DRIVER. Similarly, the DRIVER may communicate with the MAIN PROGRAM by
calling its "ComRequest(FunctionNr)" which points to "ComHandler" in the
MAIN PROGRAM. FunctionNr is just a constant that says WHAT should be done
by the handler. A list of these can be found in bwGLOBAL.PAS.

This may sound confusing but it is NOT, its the HEART of my engine - and I
LOVE IT! This means that any driver could be extended to become PRINTER
DRIVERS, etc. by setting up and handling extra FunctionNr's in the
"ComHandler" routine on the DRIVER. Hmm, it also sounds a bit networky with
all that "communication" and stuff - BINGO! It is also an efficient method
of doing stuff across a network, however I have not thought much about that
yet...

Now, back to the OBJECT problem. One of the FunctionNr's provided by the
standard driver is to return a pointer to the SCREEN OBJECT. So, the user
can have direct access to the screen via this object. The code below shows
how simple it is to do this:

    Var
        Screen : bwPBaseBitmap; { Screen Object }
    Begin
        Error := ComRequest^(bwComGetScreen,@Screen);
        If (Error <> bwErrAllOK) Then
            Return(Error);
    End;

This above code is actually never needed because it is automatically done
when you initialise a graphics mode. The code for this is "bwGraphInit" in
bwGRAPH.PAS.

Therefore, the VGA.DRV file contains both the communication handlers, and
the object definition/methods of the screen. If you take a look at the code
this will become clear - its very simple (for me anyway)!

The default screen/bitmap object is called "bwTBaseBitmap" and you can find
the definition for it in bwGLOBAL.PAS. This object is overridden by
"bwTBitmap8Bit" (bw8BIT.PAS) which implements 8 bit bitmaps in memory. In
future, I will add other objects for 16, 24 and 32 bit bitmaps. The VGA
driver (VGA.PAS) overrides the "bwTBitmap8Bit" object.

The base screen object (bwTBaseBitmap) is set up so its easy to write
drivers for harware accelerated graphics cards. So, a driver only needs to
override the "PutBitmap" procedure on a board that supports hardware
blitting. As a pleasant side effect, this overriding creates small driver
files - Just take a look at VGA.DRV and VGA.PAS.

If you have any more questions please mail me. Im happy that I can tell
someone else my thoughts and ideas...


 ________________________    e-mail: bernie@icenet.com.au
|  _)        | |                     ptschirrenb@cc.curtin.edu.au
|___)ernhard |_|schirren             tschirre@cs.curtin.edu.au
                             www:    www.geocities.com/CollegePark/Quad/8070/

Bernhard Tschirren (bernie@icenet.com.au)