GAUGE is NOT currently usable in any large-scale gaming project! Many people have e-mailed me asking how to do things with GAUGE that can't be done yet. I am sorry if this page has misled people, but the fact is that GAUGE is nowhere near complete, and is just not capable of supporting anything more than the simplest of games at this time. This will, of course, change, in the future. :)

GAUGE already has more features than I can list, but here are a few:

  • Rendering features
    • Full "6DOF" 3D rendering (duh...).
    • Can render dynamically lit, textured triangles, using any and all hardware accelleration available, including T&L.
    • Rendering plugins have been written using both OpenGL and Direct3D.
    • Can load various model formats through plugins, including 3DS, MD2 (temporarily broken), and GMDL (GAUGE's custom format).
    • Can load various image formats through plugins, including JPEG, PNG, GIF, BMP, TGA, and PCX.
    • Easy-to-use object oriented interface to rendering system. Basically, you tell GAUGE "I want this model rendered at this location," and GAUGE figures out the rest.
    • Alpha-blended transparency.
  • Other features
    • Compiles and runs under Linux/GCC and Windows/MSVC. More ports to come!
    • Functionality for loading config files in an extended version of the old win.ini format. GAUGE's version of this format allows you to have sub-sections within sections (infinite depth).
    • Compressed archive formats can be loaded through plugins. At this time, no such plugins have been written, however.
    • Object-oriented abstract file I/O interface allows files and directories on disk to be treated the same as those which are part of archives, or any other type of file or directory. Even the contents of config files are accessed using a directory structure.
    • Virtual filesystems can be built in RAM.
    • Custom I/O stream classes which allow for text or binary I/O, automatic endian swapping, stream buffering (or lack of buffering when prefered), and easy adaption to any data source.
    • Custom string class which can operate on either unicode or ASCII character data.
    • Custom light-weight object loader which can search for the correct plugin to open a file or to perform some function. That is to say, the calling program does not need to know what plugin it is loading. You just say, "Object loader, find me an image plugin which can load this here file."
    • Input messaging system which makes it trivial to re-map controls based on a config file.

Future features

Here are some things which we plan to implement in the future. Again, there is way too much for me to list everything here, but these are some key features.

  • Real-time dynamic level of detail, both in terms of geometry and per-pixel operations. GAUGE will automatically adjust detail levels depending on hardware constraints and scene complexity. Thus, you will be able to tell GAUGE to run at a specific framerate, and it will adjust detail levels automatically to keep that rate more or less constant.
  • Sector/portal based scene rendering system. Sectors will be concave (VERY different from convex sectors!). Each sector will be allowed to use its own internal rendering algorithm, possibly loaded from a plugin. So, a sector could use a BSP tree internally, or a fractal terrain rendering algorithm, etc. Portals will be allowed to violate laws of 3D space, allowing things like teleporters where you can see the other side, or portals which look back on themselves to create a reflective surface.
  • Ability to apply multi-layer surfaces to objects. This is an extension of texturing. One layer of a surface might be the color map (like a normal texture), while another layer could contain a normal map (dot product bump mapping), and yet another layer could contain a gloss map. The renderer will apply the surface in the optimal way for the hardware, possibly rendering in a single pass on GeForce and Radeon cards. Other possible surface layers include detail maps, translucency maps, opacity/alpha maps (the last two are different!), elevation maps, and more.
  • Rendering plugins optimized for various graphics cards. For example, there would be a plugin for NVidia GeForce cards which would use vertex buffers, register cominers, vertex programs, and everything else that the GeForce line offers. Meanwhile, another plugin, optimized for the ATI Radeon, would use the Radeon's triple-texturing ability to reduce the number of passes required to render a surface.
  • Advanced, object oriented sound system, constructed in a similar way to the rendering system, with support for 3D positional and evironmental sound, hardware mixing, etc.
  • Scripting support, possibly using Python. Ideally, the only code which will differ from game to game will be the scripted code. Since this code is platform-independent, any GAUGE-based game will be able to run on any OS automatically with no porting effort required.
  • Client-Server networking architecture (duh).