hill@evax.arl.utexas.edu (Adam Hill) (12/03/90)
This LONG article was posted on BIX and I thought it might be relevent to
24 bit framebuffer discusions. This proposal has been implement with a Amiga
connected to a PC with a Hercules Graphic Station card.
Its LOOOONG so hit 'n' if not interested. Enjoy!!
------------------------- Begin Article --------------------------------------
amiga.dev/standards #995, from chrisgreen,13329 chars, Sat Dec 1 14:40:24 1990
This is a comment to message 994.
There is/are comment(s) on this message.
--------------------------
A proposal for a simple 24 bit graphics standard
================================================
This standard is a minimum (though extensible) set of
primitives needed for interfacing with a graphics device capable
of displaying photo-realistic images.
The overriding factor in its design is simplicity. For
it to catch on, it should be extremely simple to implement for
a board manufacturer or distributor, and equally simple for
an application programmer to use.
This standard should be compatible with any device capable
of rendering pixels in any color space. A driver could also be
implemented for the Amiga's native display modes, including SHAM
and dynamic hi-res.
It is expected that a programmer familiar with the target
hardware and Amiga operating system could implement a simple compliant
driver in one day.
Overview
========
A user rendering true color images will have a number of
libraries resident in his system, one for each display device present.
These device are found by a wildcard search of the LIBS: directory
and by scanning the library list for patterns of the form "FB*.Library".
For instance, an amiga with no extra frame buffer devices might
contain a file called "FBAmigaSHAM.Library" which would support the
so-called "sliced HAM" mode.
Each of these shard libraries need contain only seven different
functions. Frame buffer devices may be shared by multiple programs
at the same time either through multiple pages of display memory,
or a windowing system running in the .Library or on the remote device.
The library calls
=================
GetModeTable
struct ModeTable *GetModeTable()
This function returns a pointer to a static structure which
describes the capabilities of the display device. It is a linked list
of ModeTable structures, terminated by a null pointer.
struct ModeTable {
struct ModeTable *Next; // pointer to next entry in list or 0
UWORD ModeNumber; // the number of this mode.
UWORD MaxXRes,MaxYRes; // the x and y max resolution in this
// graphics mode.
UWORD NaturalXRes,NaturalYRes;
// the "natural" resolution of the mode.
UWORD PxSize, PySize; // specifies the size of a pixel in
// this resolution in 1/65536 of an inch
units.
UWORD bitsperpixel; // number of bits per pixel.
ULONG displayflags; // display flags for this mode
char *description; // description of mode.
ULONG extrainfo // for future expansion
};
The following display flags are defined for now. All others should
be zero:
bit 0= MF_INTERLACED - If 1, this indicates that this display mode
uses interlacing. This filed would only be
used to give information to the application
user when s/he is selecting a display mode.
bit 1= MF_RECORDABLE - If 1, this indicates that the display
mode is compatible with the NTSC graphics
standard and thus can be recorded on a VCR
type device.
The MaxXRes and MaxYRes fields specify the maximum resolution
available in this display mode. This will always be greater than or
equal to the "Natural" resolution of the mode. Selecting a resolution
higher than the natural resolution may imply overscan or scrolling or
both.
For example, for Amiga SHAM mode, the "natural" resolution
in non-interlaced mode might be 320x200. The maximum size might be
360x480 overscan. Or it might be even larger if the driver supported
scrolling.
Note that the presence of a mode in the table does not guarantee
that you will actually be able to create a display in that mode; there may
not be enough memory available to do it, or the board may only support
one page at a time and it could be in use by another application.
Since this structure should never be modified by an application
program, a pointer to the actual structure in the driver can be returned
by the call.
AllocPage
D0=void *AllocPage(mode,xres,yres)
D0 D1 D2
This function returns a handle to a displayable section of
memory on the graphics device. A null pointer is returned if it was
impossible to create the display for some reason. Upon a successful
return from this call, the new memory should be made displayable,
and cleared to a background color.
The return result, P should be preserved and passed to any
graphics calls which use that page. Upon termination, the value should
be passed to FreePage().
FreePage
FreePage(p)
A0
This call frees the resources allocated to a page of memory.
Note that it is okay for this call to leave the image displayed if
there is noting underneath it to be exposed. In fact, it could
leave a window movable, sizeable, etc. until its resources are needed,
so that the user could look at it.
SetIndex
SetIndex(p, x, y)
A0 D0 D1.
This function sets the X/Y coordinate that successive pixel
should be written to. Pixel ordering is with 0,0 at the upper left.
Successive pixels will be written in left to right, top to bottom
order.
No bounds checking is done by this call.
WritePixels_32
WritePixels_32(p, n, adr)
A0 D0 A1
This function writes N successive pixels from address ADR in Amiga
memory, to page P.
Pixels are stored in the form 0RGB, i.e. each pixel occupies
4 bytes. The high byte should always be zero. On boards that have extended
attributes, they could be stored in this byte.
The driver should do any necessary translation of colors, including
dithering. Gamma correction could also be done.
SpecialOperation
D0=SpecialOperation(p, op, block)
A0 D0 A1
This function is used to execute some special operation which is not
addressed by this standard. It can be used to execute special functions
supported by the hardware if some display device. It is hoped that these
special operations can be standardized as well, in a similar manner to the
way that IFF types are. For instance, if one special operation is frame-grab,
it should be the same command on any board that implements this capability.
Parameter OP is the operation number, from 0 to ?. A0 is a pointer
to an operation dependent parameter block. The return code, D0 is operation
dependent.
An unimplemented special operation could cause a crash. Always check
via IsSuported().
IsSupported
D0=IsSupported(p, fn)
A0 D0
This function returns TRUE (-1) in D0 if a given special operation
is supported by the display driver. It can be used to check for a certain
capability, and emulate it in software if not found.
Notes
=====
Special operations:
The following special operation is defined in this draft of the
standard:
OP_READPIX32 (=0)
This operation will read a set of pixels from a page of
the display memory. The first longword of the parameter block
specifies the number of pixels to be read. The second longword
is a pointer to the destination memory. The data will be
retrieved in 0RGB format.
Note that this function may not be supported on all devices,
and if it is supported, what you read may not always match what
you wrote, because of dithering, bit truncation, transformations,
etc.
This function could be used to implement a "save-screen"
type program.
About windows, screens, paging, etc:
This standard deals with "Pages" of display memory. These
can be implemented in any way, at the discretion of the driver
programmer, and depending on the hardware capablities of the
device:
No paging : There is only one displayable page at a time, and
only one program can access it at a time. This is the
simplest method.
Multiple pages: There are multiple pages, which can be switched
between by the user. This would be implemented by either
having multiple pages dispalyable memory, or by fast
page copy operations.
Scrollable pages: These are the same as the amiga screens, and allow
you to see different non-overlapping portions of pages
at the same time.
Movable windows: These are the same as the amiga windows. Multiple
pages are displayed on the same screen surface. The user
can arrange them in dpeth, position, and size to expose
what s/he wants to see.
All interaction with these displays is the domain of the
device driver writer. Drivers using normal amiga display modes
would use intuition to allow the suer to depth arrange windows/
screens. A device driver using a connected graphics terminal would
have the interaction handled remotely. An add-in amiga frame buffer
using a separate monitor would install an input handler which
would capture special keys to switch between display pages. Pull-down
menus with special functions to save pictures, adjust parameters, etc.
could also be present.
About the index:
The SetIndex call sets the index for subsequent reads/writes.
All read or write operations adjust this to point to the next
location after the data read or written. An implementation of this
function would modify values in the Page structure which was passed
to it.
Sharability:
All calls in this library should be implemented in a
sharable manner. For a simple device which can only display
one page at once, this merely means that you must lock a semaphore
in the AllocPage call to make sure that only one process is able
to allocate the page at once. For a multiple page device, it may
or may not be more complicated, depending on what capabilities
you want to allow.
If an application wants multiple tasks to be able to access
the same page of display memory, it will have to implement its
own semaphore locks, so that each task can indivisably set the index
register and write pixels.
An example application
======================
A ray tracer is written to use this 24 bit standard. When the user
decides that it is time to render the picture, the ray tracing program
brings up a requester showing all of the available graphics devices by scanning
the LIBS: and library list for 'FB*.library'. This search turns up 'FBAmiga'
and 'FBImpulse' (for the amiga and impulse frame buffers, respectively).
The user selects FBAmiga. The program then opens FBAmiga.Library,
and does a GetModeTable call. It then displays a requester listing the
different modes available, using the description fields and resolutions:
----------------------------------------
|
| ( ) SHAM 320x200
| ( ) Interlaced SHAM 320x400
| ( ) Hires B/W with dither 640x400
----------------------------------------
The user than selects on of these. If he selects SHAM, the program
notices then prompts for a resolution, defaulting to the "Natural" resolution,
and limiting it to the "max" resolution. Smaller resolutions are fine, also.
The program then calls AllocPage to initialize the mode. It then
renders the picture in the selected resolution, a scan line at a time, by
calling SetIndex(p,0,y) followed by a WritePixels_32 operation. Upon completion,
FreePage is called. A file could be simultaneously written to disk in IFF24
RGB format.
An example implementation
=========================
A display driver is implemented for sale or shareware by a programmer,
or to accompany a rendering product. The display driver supports hi/res black
and white graphics on the amiga.
There is only one mode available, 16 color B/W. When the library is
initialized, a count variable is set to zero. Whenever the first page is
opened, the library calls intuition to open an overscanned hires screen, using
the preference values. As each page is opened, a window (possibly a superbitmap)
with borders is opened. Each returned Page variable points to a structure
including the window pointer, the index coordinates, and whatever else is
needed. When Pixels are written, the RGB values are comverted to B/W by
whatever tranformation looks good, dithered with a 4x4 dither, and plotted
in the window. WHen a page is closed, the window is closed, and when the
last window is closed, so is the screen.
readpixel_24 operations will return the same values for R,G, and B,
because of the black and white nature of the display.
Initial implementation
======================
I have a PC connected via serial port which has a hercules graphics
station card attached, which is capable of 24 or 16 bit true-color. An
implementation of the library, along with a sample picture viewer program
will be created.
Ideas for the future:
=====================
A standard resolution requester could be implemented and stored
in a library or released to the public domain as source code.
A good SHAM driver should be created. This would allow anyone to
render good RGB pictures with a minimum of work. Each page would be
an amiga HAM screen with a copperlist. WritePixels_24 would cause a new
palette to be created for each scanline that was modified.
A display driver that just wrote to files could be implemented.
This could be used for background rendering, or could be used in conjunction
with a display to make it easy for the application program to save its
output in IFF 24 format or whatever.
--------------------------------End of Article-----------------------------------
The author has implemented the standard via a Spirit AX-S card and a
Hercules Graphic Station Card in the PC. They communicate via a 115K serial
link.
I guess the AX-S card is of some use......
Hope you've enjoyed it.
--
adam hill
hill@evax.arl.utexas.edu Make Up Your Own Mind.. AMIGA!
Amiga... Multimedia NOW
Most Common Phrase at DevCon '90 - "Shhhhhhh.."