| The PXGDI samples are three
programs that all use the same GDI mechanism for displaying video in a window.
The differences among the programs is in their use of the queuing facility
in the PX library. See the program descriptions below. You should feel free
to use our samples as starting points for your applications.
These programs are updates
of the same programs that came on the floppies with your PX product. These
programs will work with either interlaced or non-interlaced video making
the sample PXNI.C unnecessary. If you are familiar with the earlier samples,
you will notice that the TIME TEST button has been removed. The frames
per second (fps) and DMA errors are kept up to date in the title bar of
the display window.
Note
You may notice that the frames
per second calculation is wrong for the first minute or so of operation.
If you work out the numbers you will see that the numerator has to get
quite large before we can get the right answer in whole numbers.
The GDI Method
These programs show you how
to use the Windows GDI facilities to display video in a window. As computers
become faster and faster, this becomes a very good way to display video.
It is much simpler than DirectDraw and does not rely as heavily on the
VGA drivers.
Windows provides three methods
for drawing graphics on a window: text, raster, and vector. These samples
use the raster method. An image is stored in an array called a bitmap
and then a call is made to a Windows function that describes how to display
the bitmap. A bitmap consists of a header and an upside-down representation
of an image.
In the following programs,
we set the header with the function SetBitMapHead(). We flip the image
upside down with the function GetImage(). And we send the image to the
screen with the Windows function SetDIBitsToDevice(). You can also use
StretchDIBits() but it is slower. Don't use StretchDIBits unless the image
and window are different sizes. SetDIBitsToDevice() is the fastest way
to move an image to the VGA card when the image size does not need to
change.
The complete algorithm for
grabbing and displaying an image is as follows:
Grab();
GetImage();
SetDIBits();
The bitmap header is set during
initialization and never changed. After the grab, the image is flipped row
by row in GetImage() and displayed. The work is divided between the functions
AppPaint() and AppIdle().
Notes on Compilers
In order to make compiling
and linking easier, you can add our LIB and INCLUDE directories to the
directories that your compiler and linker normally search. Our libraries
are not installed in your compiler's LIB directory. You must explicitly
link your program with any third party library like ours.
Borland
You must use Borland C/C++
5.0 or newer to link with our import libraries. The older Borland compilers
use a different library structure and you will see an error that says
the library is corrupt.
Borland compilers and linkers
use the TURBOC.CFG file to locate libraries and header files. The TURBOC.CFG
file can be found in your compiler's BIN subdirectory. For example, if
you have the Borland 5.0 compiler, the TURBOC.CFG file will be found in
C:\BC5\BIN\TURBOC.CFG.
It normally contains the following
two lines:
-IC:\BC5\INCLUDE
-LC:\BC5\LIB
You can modify it to include
the PX5 subdirectories as follows:
-IC:\BC5\INCLUDE;C:\PX5\INCLUDE
-LC:\BC5\LIB;C:\PX5\LIB
Microsoft
You need to use Microsoft C/C++
4.0 or newer to link with our import library.
Microsoft compilers use environment
variables to find LIB and INCLUDE directories. You can add the PX5 directories
to the existing values. These variables are typically set in your AUTOEXEC.BAT
file or in the System Applet in NT.
SET INCLUDE=C:\MSDEV\INCLUDE;C:\MSDEV\MFC\INCLUDE;C:\PX5\INCLUDE
SET LIB=C:\MSDEV\LIB;C:\MSDEV\MFC\LIB;C:\PX5\LIB
If you are using a Windows IDE
with either Borland or Microsoft, you can set these same values as defaults
in the IDE, or you can include the libraries as part of your project file.
The PXGDI Sample Programs
PXGDI1.C
This is the simplest and slowest
sample. It uses a NON-QUEUED grab which means it wastes 33 ms waiting
for the grab to complete. Then it flips the image and copies it to a window.
This sample has a maximum theoretical speed of 20 frames a second if it
can get the display done in 1 field time (16 ms). That means it would
grab a frame, skip a field, grab a frame, etc.
PXGDI2.C
This sample is similar to PXGDI1
except that it uses a QUEUED grab. When the current grab is complete,
it flips the image and then queues the next grab. While the next image
is being acquired, the current image is sent to a window. This program
makes up for the lost fields in PXGDI1. However, it does lose 1 field
time in flipping the image. This sample, therefore, has a maximum theoretical
speed of 20 frames per second. Although it sounds as if this sample does
not improve on PXGDI1 at all, it really does. PXGDI1 will typically have
a maximum speed of about 15 fps unless the processor and the VGA card
are extremely fast. It takes very little time to flip the image in memory,
because it is just a memory copy. However, the display time can vary quite
widely depending on the VGA card and its drivers.
PXGDI3.C
This sample uses QUEUED frame
grabs and DOUBLE BUFFERING. It keeps the image buffers full by using 2
queued grabs. It flips an image and requeues the next grab while it sends
the image to a window. If this sample can flip an image and requeue the
next one fast enough, it can achieve a speed of 30 frames per second.
On most newer computers, this sample should display 25 (CCIR) or 30 (NTSC)
fps. In the early days of Pentiums that was not true, but today with speeds
between 400 and 700 MHz it should be quite easy to reach real time display
with a monochrome camera.
|
