newspeoplefor developersdocumentationdownloads

Overview of Nebula 2

Systems

See also Contributed Modules for Nebula 2.

High-level Features

  • Shader Based Graphics: Nebula 2 is 'shader-centric': all render state is handled by the shaders. It's possible to render many effects without changing any C++ code, just by writing new shaders. Shader parameters can be created and altered from the in-game console. The DX9 implementation uses Direct3D Effect Files (.fx).

  • Animation: Many things can be animated in Nebula 2: shader parameters, position, rotation, scale. The animations can be driven by time or any other variable of your choice, and you can choose from step, linear and quaternion slerp interpolation.

  • Hierarchical Object Name Space: Nebula 2 objects live in a hierarchical tree of named nodes similar to a file system hierarchy. An object name can be converted into a C++ pointer and a C++ pointer can be converted into a name at any time. Having named objects around is very convenient when referencing objects through the script interface, or in their persistent state. Runtime efficiency doesn't suffer from this, since normally, references by name are resolved into references by pointer only once at load/initialization time. During an object's lifetime, references to other objects are normally kept as cached C++ pointers.

  • Scripting: Scripting in Nebula 2 means sending script commands directly to C++ objects. Nebula 2 objects come with 2 interfaces: their C++ interface for runtime efficiency, and a script interface for flexibility. The script interface is as close to the C++ interface as possible to minimize work on the dispatcher code (around 3..6 lines of codes per script command). Internally, script commands are handed around in language independent binary packets, which are translated by a script server object into and from a specific script syntax. Nebula 2 can be used with many script languages and switching to other is just a matter of writing new script server classes. See Nebula 2 Script Interface for information on how to control Nebula from script.

  • Networking: A running instance of Nebula 2 can be controlled, via the script server, from another process on the local machine or another remote machine. This is mainly used for debugging. There is also a game oriented networking layer (see Network/Multiplayer Subsystem).

  • Object Persistence: Nebula 2 objects survive on disk as scripts that contain exactly the sequence of script commands that would put a default object of that class into an exact clone of the object which created the script. Since the object persistency mechanism reuses the script interface there is no conceptual difference between a "Nebula script" and a "Nebula data file". A binary "script server" also allows objects to be saved out in a compact, efficient binary representation that can be loaded quickly.

  • Gui: Nebula 2 provides a full blown system for providing themeable user interfaces within the game.

Historical Documents

Copyright © 1999-2005 by the contributing authors. Ideas, requests, problems: Send feedback.