home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Club Amiga de Montreal - CAM
/
CAM_CD_1.iso
/
files
/
505b.lha
/
Ham_e_library
/
renderlib.doc
< prev
next >
Wrap
Text File
|
1991-05-05
|
10KB
|
214 lines
=----------------------------------------------------------=
| renderhame.library |
=----------------------------------------------------------=
Provides high quality rendering "in a can" for applications
needing to write HAM-E format images.
------------------------------------------------------------
Last updated for version 1.0 --------------- April 19th, 1991
------------------------------------------------------------
Copyright Notice:
=================
"renderhame.library" is Copyright 1991 Black Belt Systems, ALL RIGHTS
RESERVED under the Pan-American conventions.
Disclaimer and Agreement for Use:
=================================
This software is provided as is. Black Belt Systems takes no
responsibility for data manipulated with this software; or for the
interpretation of such data. The user is entirely responsible for the
interpretation and use of image data manipulated with the
renderhame.library software and the HAM-E. The user is also responsible
for observing the Copyright restrictions on materials manipulated with
the renderhame.library. Black Belt Systems will make solid efforts to
maintain this library in a reliable, bug-free form, but cannot be held
responsible if problems with the software incur losses of any type upon
the user. The user is responsible for reporting bugs to Black Belt
Systems. If these terms and conditions are not acceptable to the user,
then Black Belt Systems declines to issue permission to the user to use
renderhame.library in any manner for any purpose whatsoever.
Renderhame.library software project credits:
============================================
Programming
-----------
Pete Patterson --- Library implementation, conversion of all routines
used to reentrant code methods, recoding of most of
the IFF saver.
Ben Williams ----- Spectral color render code and methods, 24 bit color
space methods for EDD dither and Hi-Q ham-e render.
Tom Krehbiel ----- Hi-Q 18 bit ham-e mode render code.
Matt Dillon ------ Original PD code that the IFF saver was derived from.
Documentation
-------------
Pete Patterson, Ben Williams
Funding
-------
Black Belt Systems - Support for the HAM-E project.
Introduction
============
This library provides three functions which were not included in the
hame.library because they are fundamentally different from low-level
hame code. Two of these functions provide HAM-E mode and REG mode
rendering routines while the third provides a basic IFF file save
function. The library must be present in the libs: directory on any
system wishing to use these functions.
It is important to note that all of these routines require that
the hame.library also be present, and that it is not possible to use
these routines without also using the hame.library.
In addition to the structures defined and used in hame.library, there is
one additional structure that is defined for use by the render.library.
Here is the definition of the rgb_image structure used by the rendering
routines:
struct rgb_image
{
/* User portion */
int xsize, ysize; /* fill these in before using*/
unsigned char *rbu, *bbu, *gbu; /* fill in these too */
/* Private portion */
int last_reg; /* leave all of the rest alone */
short *ooxmap, *ooymap;
UBYTE *CubeLookup;
UBYTE Palette24[(3*256)+4];
unsigned char reg_mem[256][3];
unsigned char reg_memx[256][3];
unsigned short *cspace;
struct HamePort *HamePort;
int u_r_here;
};
Please note that the only variables we sanction the use of within the
rgb_struct are the xsize, ysize, rbu, gbu and bbu parameters. The rest
of the variables are private data used by the rendering routines.
To use either of the rendering routines, you must fill in the first
five members of the rgb_image structure. The xsize and ysize members
indicate the width and height of the image represented by the RGB data.
The rbu, gbu and bbu members are pointers to the red, green and blue
data buffers. These buffers do not need to be in CHIP ram, and in fact
performance will be adversely affected if they are in CHIP ram.
The data in the red, green and blue buffers consists of single bytes,
each of which is interpreted as an unsigned color component value.
Color component values range from 0-255 and when three of them are
taken together a 24 bit color number is obtained.
The data itself should be organized in row,column order. That is, if
the data is scanned in order from the start address toward increasing
addresses, the data should represent the first row of data from left to
right, followed by the second row of data from left to right etc. The
total amount of data should be equal to the xsize times the ysize.
Once your data is in your buffers and your rgb_image structure is
initialized, you need to get a HamePort pointer upon which to render
the data. Decide wether you wish to render in Ham mode or register
mode, and read the documentation on the hame.library to find out how to
open a HamePort. Your RGB data will be rendered to fill the entire
HamePort, so define your HamePort and screen accordingly.
Both of the renderers avoid using color 0 for any reason, thereby
avoiding the possibility that blank lines will occur in the image and
inadvertently turn off the HAME. In addition, both color 0 and color 1
are set to black. Color 1 is used as a reference black within the
image, and color 0 is used only where the Amiga sends all-zero data
(such as at the edges of the image, in the overscan regions).
After you have obtained a valid HamePort pointer, you can go ahead and
render your data. The following section describes each of the two
rendering options:
void HAME_RenderHam(struct HamePort *h,
struct rgb_image *rgb,
long left,
long top,
long wide,
long high,
long ebit);
This rendering function uses the HAME mode to produce the most
accurate color display possible. The HamePort and rgb_image
pointers were described above. The left and top arguments describe
the location of the upper left corner of the source region you wish
to render while the wide and high parameters specify the width and
height of the source region.
The indicated source region of the RGB buffers will be rendered into
the specified HamePort, filling the entire HamePort as defined in your
HAME_Init call. (see the hame.library docs for details) You should make
sure that you opened the HamePort in ham mode, or else the results will
fall far short of your expectations, IE look terrible.
The "ebit" parameter is used to tell the library whether you want
the render to be done to eighteen bits precision, or if you want
the special 24 bit render techniques used. If you use 18 bit
techniques, then the image will be slightly less prone to fringing
in some cases where color changes are large and rapid. If you use
the 24 bit technique, the image will be rendered to a full 24 bit
accuracy, using a combination of carefully chosen (and placed) 24
bit color registers, and the EDD dithering techniques developed by
Black Belt Systems. 24 bit renders take slightly longer (10% or
so), and for the most part this is what the user is likely to want.
Set 'ebit" to 1 or 0 to tell the library what you want it to do.
void HAME_RenderReg(struct HamePort *h,
struct rgb_image *rgb,
long left,
long top,
long wide,
long high,
long edd,
long last_reg);
This rendering function uses register mode to produce its display.
The HamePort and rgb_image pointers are as described above. The left
and top arguments describe the location of the upper left corner of
the source region you wish to render while the wide and high parameters
specify the width and height of the source region.
The indicated source region of the RGB buffers will be rendered into
the specified HamePort, filling the entire HamePort as defined in your
HAME_Init call. (see the hame.library docs for details) Make sure that
the HamePort was opened in register mode, or the render will look
terrible.
The edd parameter allows you to specify special dithering
techniques that will extend the 256 available colors far beyond the
actual 256 color segment of the color space that they occupy. In
most cases, this is what you want. In some images, EDD may induce
more "graininess" than you want; more often, the image will be
actually smoother to the eye as a result.
The last_reg parameter allows you to limit the number of registers
used by the renderer. This is a convenience feature that allows
you to keep some of the registers for your own use, without your
color choices adversely affecting the picture quality.
int HAME_SaveIFF(struct HamePort *h,
char *name);
This is a simple IFF save function provided as a convenience.
(We're humanitarians - well, maybe we're not, but it sounds nice :^)
Pass it your HamePort pointer and a FULL filename, and it will
save the screen as a standard 16 color IFF file that can be viewed
with any standard IFF viewer.