This document should be used in conjunction with the main documentation, and the source documentation.
The GBMOS2PM package consists of source code and executables for a few OS/2 specific programs and libraries, which make use of GBM.
GBMDLG is a DLL which programs may use to select bitmap filenames to load or save. Includes IPF help applicable to the process, and which documents the formats and levels of support given by GBM.
usage: gbmv [-e] [-h] [--] fn.ext{,opt}
flags: -e error diffuse
-h halftone
-e and -h not allowed together
fn.ext{,opt} input filename (with any format specific options)
bitmap formats and options as before
GBMV is a simple PM program for displaying a bitmap. It can used error-diffusion or halftoning to improve the quality of image display.
usage: gbmv2 [fn.ext{,opt}]
fn.ext{,opt} input filename (with any format specific options)
bitmap formats and options as before
This is the flagship interactive bitmap manipulation program. It can perform any of the functions of the GBM package, which operate on a single bitmap.
It has full online context sensitive help, and an undo option. Interaction with the PM printer and clipboard is possible also. The PM Desktop may also be snapshotted. Also included is export to Metafile capability.
GBMV2 uses the GBMDLG library when the user is required to provide bitmap filenames.
usage: gbmvfsa [-l] [-p] [-s] [-t] [-P] n1 n2 n3 fspec{,opt}
flags: -l loop indefinately
-p set palette only once, assume same
-s single step the frames
-t annotate each frame with its title
-P display palette bar
n1 n2 n3 for ( f=n1; f<n2; f+=n3 )
fspec printf(fspec, f);
filespecs are of the form fn.ext
bitmap formats and options as before
This program can be used display an animation consisting of a collection of individual bitmap frames.
It displays the animation to the OS/2 Full Screen 320x200 at 8bpp VGA screen mode. Because of this, GBMVFSA is limited to displaying bitmaps of 320x200 or less, and they must be 8bpp. Also, all the bitmaps must be the same size.
If all the bitmaps share the same palette (presumably enforced by
using GBMCPAL) then specify the -p option.
If the bitmaps have different palettes then visual artifacts can be produced. This is because for each new frame, the palette is changed, and then the screen bitmap bits are changed. Thus there is a small window in which the old bits are displayed with the new palette. At this time I know of no architected way to synchronise the changes to occur with the vertical retrace, using the OS/2 Vio API.
One way to avoid the problem is to have each bitmap use 128 colours. Even bitmaps would use palette entrys 0 - 127, and palette entries 128 - 255 would contain the previous pictures palette. Similarly in reverse for odd bitmaps.
GBMCPAL (from the base GBM package) provides an attempt at solving the
problem.
Its rofreq and romcut options reorder palette
entries to try to minimise changes between successive frames.
This significantly reduces flicker.
In most cases, flicker can be totally eliminated.
The important thing to note is that it is not GBMVFSA's job to solve this problem, it is the job of the bitmap generating program.
For example, here is what I did to make a spinning globe animation.
First I traced a largish number of individual bitmap frames using my
raytracer, RT.
I wrote these out under the names globeNNN.tif where
NNN is 000, 010, 020,
... 350 (ie: the angle of rotation in degrees).
I used the ,lzw option to get the files
written LZW encoded to reduce the disk space requirements.
Then to map the data to a common palette, I used GBMCPAL :-
gbmcpal -m freq6:6:6:256 0 360 10 globe%03d.tif globe%03d.bmp
To display the animation under OS/2, using fullscreen VGA, I use :-
gbmvfsa -l -p 0 360 10 globe%03d.bmp
Obviously there are file formats specifically for holding animations, and algorithms for having animations where palette entries vary from frame to frame, but the simple example above is ok for many purposes.
As the program runs, certain keys can be used :-
Space advances a single frame - steps back one frame 0 .. 9 moves to 0/10 .. 9/10 of the way through s enters single step mode g resumes continuous play t toggles titleing on/off p toggles palette display on/off Esc,q,x quits
usage: gbmlogo [-e] [-hN] [--] filename.ext{,opt}
flags: -e error-diffuse to RGBI
-hN halftone to RGBI
N is a halftoning algorithm number (default 0)
-e and -h can't be used together
filename.ext 640x400 bitmap
bitmap formats and options as before
At boot time OS/2 looks for the file \OS2LOGO and
displays this as the boot logo.
This logo is in a special format, compressed using the EXEPACK algorithm.
The IBM OS/2 Developer Connection CDs have included a tool called
MAKELOGO, which takes dumps of the R,G,B and I planes
from the VGA frame buffer, and writes an \OS2LOGO.
GBMLOGO takes in a 640x400 bitmap in any format, and writes out the files needed by MAKELOGO.
Just unzip the GBMOS2PM package and copy all the .exe,
.dll and .hlp files into a directory somewhere.
If you've already got the GBMOS2 package installed into a directory, you might as well put these new files in there too.
This directory ought really to be on the LIBPATH, and also
on the HELP path, in the CONFIG.SYS.
In order to compile the supplied source, you need the GBMSRC package, as this contains assorted GBM headers and libraries.
The gbm.h, gbm.lib and gbm.dll
supplied with the GBMOS2 package are only sufficient from writing programs
which only make use of GBMs file load and save facilities.
If you want to do any image manipulation, you need stuff from the GBMSRC
package.
The makefiles refer to the directory where the GBM source
code is via the GBM make variable towards the top of the file.
This will typically be \build\os2\graphics\gbm by default
(as this is where I tend to put GBM on my build machine), but you will
almost certainly want to change this for your setup.
The source can be compiled using VisualAge C++ 3.0 (with CTC306, CTD302 and CTU304).
The GBMOS2PM source is divided into a set of directories, each of which defines a sub-project :-
./gbmv
./gbmdlg
./gbmv2
./gbmvfsa
./gbmlogo
VRAM0.DAT, VRAM1.DAT,
VRAM2.DAT and VRAM3.DAT for feeding into
MAKELOGO.EXE as supplied on Developer Connection CD 6.
MAKELOGO.EXE makes VRAM.DAT which can be copied
over hidden file \OS2LOGO on the boot drive, to change the
boot screen.
Input to GBMLOGO.EXE should be a 640x400 bitmap.
The sub-projects should be built in the order listed above, because later sub-projects use headers/librarys etc. from the earlier ones.
The GBM packages are best obtained via the links on my home page(s) :-
http://www.interalpha.net/customer/nyangau/
http://grob.ssd.hursley.ibm.com/ (IBM internal network).