What's WOC All About? |
|
| SDK source code is
verbose I learned Windows® programming by writing Platform Software Development Kit (SDK) programs in C and later C++ and I loved it. The Windows API is suited to assembly language and C and consequently it fosters a procedural model of programming. It also didn't escape me that much of a Windows program is common boilerplate stuff along with a fair bit of other unattractive, nuts-and-bolts code which doesn't lend itself to easy reading. The most popular object-oriented Windows application framework and Win32® API wrapper classes is the Microsoft Foundation Classes (MFC) which can make Windows software development incredibly fast and intuitive, and hence MFC is a pleasure to use. However, MFC must be either linked-to dynamically on the target machine (which introduces DLL distribution and versioning concerns) or be statically linked into the application (which unduly bloats the executable). For these reasons MFC is regarded as being best suited to GUI applications where optimal runtime speed can be traded for accelerated productivity. But there are other types of application where tight, fast code is the deciding factor. These types of application are those involving OpenGL or other graphics libraries, Windows CE (because of hardware limitations) and COM (partly because ActiveX Controls must be small for rapid network distribution). |
|
| Existing solutions Of the application types just mentioned, COM is taken care of with the excellent ActiveX Template Library (ATL) which is strongly preferred over MFC. ATL, like the C++ Standard Template Library (STL), is designed to be very efficient as well as flexible and extensible. That leaves OpenGL and Windows CE applications. Although Mark Kilgard's OpenGL Utility Toolkit (GLUT) is available and popular, it addresses the issue of source code portability between OpenGL platforms rather than the performance and readability of applications specifically for Windows. GLUT can generate the geometry of spheres and tori, etc, but it is lower-level than WOC and does not relieve the programmer of scene- and model-management, transformation, texturing, lighting and animation responsibilities. Nor does it support the reading of geometry from files. Windows CE is just a limited Win32 platform so MFC is also an option, but not if you want to exploit every processor cycle your portable PC can muster. For me, programming the Win32 API directly is the best option for OpenGL and WinCE software. But to maximise readability and reusability of source code, there's much to be learned from the approaches of MFC and ATL. |
|
| What WOC offers WOC is a hierarchy of template and non-template C++ classes, functions and function templates which may be used straight out of the box or derived-from and specialised. For general Win32 and WinCE purposes, there are classes which represent: the Windows application, a general window, a frame window, a view window and a dialog. Compatible with general Win32 and MFC for OpenGL modeling and rendering are classes which represent: an OpenGL rendering context view window, a texture co-ordinate, a general vector suitable for normal vectors or geometric vertices or lighting or material properties, a triangle, a texture, a light, a model and various functionality to load geometry from Wavefront .OBJ files and to generate facet or vertex normals. There is also a collection of integrated class templates which work together to provide values or value domains, functions, oscillators and mono or poly relays of pointers-to-member functions so that the transformations you define (or indeed any object with a mutator of the correct prototype) may be animated under timer control. The classes are provided purely in source code - there are no static nor dynamic libraries involved. Despite some similarities (and compatibility) with MFC, such as the ability to derive from the window class hierarchy and override message handlers, WOC lacks the full functionality of MFC and is much lighter as a consequence. WOC is designed to cater for the windowing needs only of OpenGL applications and not general Windows applications. But of course WOC offers all that 3-D model oriented functionality which is absent from MFC. Like ATL, class templates comprise part of WOC, and these templates take further classes as parameters. Just like ATL, you can derive your own classes and pass them as template parameters to instantiate your own specialised functionality. At its simplest, only a single-line variable declaration is required to begin an application, create a frame window and OpenGL rendering context view window over it, handle standard messages and render a default, normal-generated, lit, auto-rotating model in the view. Of course for more control you'll need to dervive at least one class of your own. You can find out how easy that is in the tutorials. |
|
| WOC constraints and
wishlist There are too many features missing from Version 1.0 of WOC to mention them all here, but I will mention a few. There is no support for user selection of rendered objects nor for the rendering of text, both of which limit WOC's application to 3-D controls. Transparency is also not directly supported, nor is the related issue of z-sorting objects in a scene. The writing of OBJ format files is not supported, and the reading of texture files is limited to the Windows BMP and the RAW formats. Another feature I'd like to see is the ability to optionally compile any WOC application as a screensaver. Future releases of the class library will of course address these missing features. I hope version 2.0 will have excellent support for 3-D controls - perhaps even, in concert with ATL, 3-D ActiveX Controls. |
| last updated: 19-sep-01 |