i
i
i
i
i
i
i
i
294 12. Tools, Libraries and Templates for VR
12.2.2 Compilers
If one is developing for Windows, without question Microsoft’s Visual C++
compiler is the most commonly used tool. In fact, the compiler itself is offered
free of charge b y Internet download from Microsoft [7]. The Application and
Class “Wizards” in Visual C++ make for rapid and relatively pain-free devel-
opment, and all our working programs will provide the appropriate Solution
and Project files for Visual C++ Version 6 or Visual S tudio.NET.
3
The GNU
C++ compiler [4] has been successfully ported to Windows, but on Linux
and UNIX systems it is the only real option. Apart from the OpenGL ex-
amples we will be developing, all the other programs are essentially Windows
programs. The DirectInput- and DirectShow-based application programs re-
quire Microsoft’s DirectX Version 9 SDK, which is not available for other
operating systems. However, OpenGL has a long history of platform inde-
pendence and so we will comment on how the OpenGL examples can be
constructed using the GLUT (see Section 13.2) to make them completely
platform-independent.
On Macintosh OS X platforms, the X-Code [1] suite is freely available
and totally comprehensive. By using the GLUT, an OpenGL application can
be ported to OS X with good success, as the middleware and scene-graph
applications have been. Unfortunately, we have not yet seen any Macintosh
systems with graphics chipsets that support Version 2 of OpenGL, so this
rather restricts its use in VR applications where a high realism is required.
(Alas, it is a sad fact that while there are several competing 3D chipset sup-
pliers and many graphics card manufacturers who supply the PC market, the
same can not be said for the Apple product line. Thus, Mac systems are not
the first choice for cutting-edge graphics work. We will give one example of
developing an OpenGL application for 3D mesh visualization on Mac OS X
in Chapter 13).
4
12.3 A Framework for the Applications
One way in which application programs can be developed is to start with a
basic framework and extend it. In Part II, we will be looking a t a broad range
3
The readme.txt file on the accompanying CD will give more details of the latest versions
of the compilers.
4
Macs based on Intel hardware are now available, so perhaps OS X will enjoy the benefits
of a vast selection of different graphics adapters after all.
i
i
i
i
i
i
i
i
12.3. A Framework for the Applications 295
of applications which are basically targeted at the Wintel
5
platform; therefore,
we have a choice of two types of framework on which to base our code:
• Win32. Message-based API function library for Windows.
• MFC. Object-orientated class library encapsulating the Windows API.
These identify two styles of programming: functional or object-orientated.If
you prefer to program exclusively in C then you have no choice but to use
the W in32 application framework. Applications written in C++ can use ei-
ther style. There really are no hard and fast rules as to which framework to
use. MFC applications give you a fantastically functional application (tool-
bars, neat frames and robust document handling functions) with very little
programmer effort, but they are bloated in code size. If you want to do some-
thing slightly unusual, MFC code can look quite inelegant as you break up
the structure of the tightly integrated object-orientated classes.
Since all our VR applications need high-speed graphical display, for movie
presentation or 3D visualization, we will need to use either, or both:
• OpenGL
• Direct3D
Both of these API libraries can fit neatly within either of our application
frameworks. We will consider template codes that use these libraries for 3D
rendering programs in Chapter 13. A template for using DirectInput to ac-
cess devices such as joysticks will be given in Chapter 17 and one for using
the extremely obscure DirectShow interface in Chapter 15.
In Appendices D and E, we provide two frameworks that are built on
by the examples of later chapters, but do please note: we do not intend to
give a comprehensive tutorial on writing application programs for Windows.
For that you should consult one of the large volumes with something like
“...Programming Windows...” in the title. A couple of good examples are [10]
and [14].
From these frameworks, we are almost ready to proceed to build some
working programs. How ever there is one small complication: COM. Mi-
crosoft has chosen to implement its strategy for directly accessing the com-
puter’s hardware, its HIDs and GPUs, through DirectX, which uses COM.
Whilst we could avoid COM for 3D graphical work by using OpenGL, for
any sort of video work (using DirectShow), we have no choice but to delve
into COM.
5
Wintel: a PC with an Intel x86 or compatible processor running the Microsoft Windows
operating system.
i
i
i
i
i
i
i
i
296 12. Tools, Libraries and Templates for VR
12.4 The Component Object Model
If you haven’t worked with COM before, it can be quite a shock to be con-
fronted by some of its peculiarities. A lot of the difficulties are due to the
sudden onslaught of a vast collection of new jargon and terminology. How-
ever, once you catch on to the key concepts and find, or are shown, some
of the key ideas, it becomes much easier to navigate through the bewildering
and vast reference documentation around COM. So, before jumping into the
examples, we thought it important to highlight the concepts of COM pro-
gramming and pull out a few key constructs and ideas so that you will see
the structure. Hopefully, you will appreciate that it is not as overly complex
as it might appear at first sight. Our discussion here will be limited to those
features of COM needed for the parts of the DirectX system we intend to use.
12.4.1 What is COM?
COM grew out of the software technologies of object linking and embedding
(OLE) and ActiveX [2]. It can be summed up in one sentence:
COM is a specification for creating easily usable, distributable
and upgradable software components (library routines by an-
other name) and are independent of the high level language in
which they were created, i.e., it is architecture-neutral.
The jargon of COM is well-thought-out but may be a little confusing at first.
Whilst it is supposed to be language-independent, it is best explained in the
context of the C++ language in which the majority of COM components are
implemented anyway. Any COM functionality that one wishes to provide or
use is delivered by a set of objects. These objects are instances of a class (called
a CoClass) that describes them. The objects are not created, nor used, in the
conventional C++ sense, i.e., by instantiating them directly with commands
such as new MyComObject1;. Instead, each COM class provides a series
of interfaces through which all external communication takes place. Every
COM interface provides a number of methods (we would call them functions)
which the application program can use to manipulate the COM object and
use its functionality. Thus, the key terms when talking about COM are:
• COM object. An instance of a CoClass.
• CoClass. The class describing the COM object.
i
i
i
i
i
i
i
i
12.4. The Component Object Model 297
• Interface. A pointer by which to access all the methods and properties
of a COM object.
• Method. The functions of a COM object’s interface that do all the work
of the COM object.
Earlier in this chapter, we hinted at the problems of versioning in DLLs.
There are other problems, too, such as calling external functions from within
a DLL, say, one written in C++, from BASIC language subroutines. COM
seeks to overcome this by never upgrading any object or interface. If the
authors of a COM library want to provide extra functionality, they must
define a new interface but they must not remove the original one, either.
This is one reason why one has interfaces such as ICaptureGraphBuilder and
ICaptureG raphBuilder2. COM components can still be packaged in a DLL
or as an executable. They can be located in different places or indeed moved
if necessary. Application programs know where they are by looking in the
Windows registry for their class identifier (CLSID) which has the form of
a globally unique identifier (a GUID). Before COM objects can be used,
therefore, they have to be installed into Windows. This effectively means
writing the GUID into the registry and mapping their location on disk. In a
typical Windows registry, there may be may hundreds of these COM classes.
For example, the video codec Xvid (discussed in Section 5.5.2)
can be used by any video player programs installed on the same
computer because it is implemented as a COM component. On
a typical system, the binary code for the codec is stored in the
file C:windowssystem32xvid.ax, but the key to making Xvid
available is its registration through its GUID entry in the CLSID
section of the registry (see Figure 12.1).
One of the biggest headaches for novice COM programmers looking for
example code that they can reuse is the fact that there are often many ways to
do exactly the same thing. If you read a book on COM and then turn to an
example from the Direct3D SDK, it is likely that even getting hold of the first
interface will break the rules so carefully explained by the COM purist in her
book on COM. Sadly, that is one of the things those of us who only want to
do 3D or video programming will just have to accept as the price to be paid
for not having to write every line of an MPEG-4 DVD decoder ourselves.
To try to find a path through the COM maze, all our example programs that
need to use COM will stick to one or two standard ways to get the programs
up and running.
i
i
i
i
i
i
i
i
298 12. Tools, Libraries and Templates for VR
Figure 12.1. A typical COM object has its unique class identifier stored in the Win-
dows registry.
12.4.2 How COM Works
COM is a collection of components, each one of which can expose a number
of interfaces. By convention, the names of these interfaces always begins with
the letter I. They can be repr esented diagrammatically, as in Figure 12.2.
At the top of Figure 12.2, we see an example of the interfaces
that a COM object exposes. In this case, it is the COM object in
DirectShow which controls the whole operation of a DVD/movie
playing program. Like all COM objects, it exposes the interface
IUnknown along with three other interfaces through which
application programs control playback. At the bottom of Fig-
ure 12.2 is another example of an interface. This time, it is a
DirectShow component (a filter) for a COM object that will dis-
play (render) a decoded DVD/movie to the screen. Unlike the
GraphBuilder object (on the left), which is a major component
in DirectShow, a renderer filter is often written for specific pur-
poses. We shall be writing examples in Chapter 16. In the center
of the figure is an illustration of the class hierarchy leading down
to the CBaseRenderer class an application program can use
to derive a class from in order to implement a rendering filter
that fits the DirectShow specification and implements all the in-
terfaces that a COM object requires. (It is the CoClass for the
DirectShow renderer filter COM object.)
Like C++ classes, interfaces can inherit properties from their parent interface,
and all COM objects must expose at least one interface, which is known
as IUnknown.IfIUnknown were the only interface that a COM object
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.