Release Notes for Build 133
Release date: April 6, 2007
- FBOs are now enabled by default on the Mac. They seem to be working correctly in MacOS 10.4.9.
- The
System
class has been removed from the engine, and its functions have been moved to theEngine
class. All occurrences ofSystem::
andTheSystem->
should be changed toEngine::
andTheEngine->
, respectively.
- With the intent of reducing the number of steps required to register custom class types, the registration mechanism has been changed a bit. First, for all registration types, it is no longer necessary to explicitly call one of the
Register*()
functions. Instead, every registration type automatically registers itself upon construction. Calls to the following functions should simply be removed:RegisterController
RegisterProperty
RegisterMethod
RegisterMutator
RegisterEffect
RegisterEntity
RegisterFunction
- Second, there is a new, slightly different way to declare registrations for controllers, properties, methods, mutators, effects, particle systems, and functions. Instead of declaring a controller registration object as a
ControllerRegistration
, you should declare it as aControllerReg<type>
template object, where type is the derived type of the custom controller class. For example, the registraton for theRotationController
class is declared asControllerReg<RotationController>
. The following templates exist for registering various types of custom classes:ControllerReg<type>
PropertyReg<type>
MethodReg<type>
MutatorReg<type>
EffectReg<type>
ParticleSystemReg<type>
FunctionReg<type>
- Custom class types registered with these templates no longer need to be constructed explicitly by the application. If you've implemented a function such as
ConstructController
, then you can remove any registered types because they will be constructed automatically.
- The function registration object is a little different in that its constructor takes a pointer to a controller registration as its first parameter. Function registrations for each type of controller are stored in the controller's registration object. There is no longer any need to implement a
ConstructFunction()
function in controller classes that define custom functions.
- Previously, registration objects for controllers, properties, and mutators took a parameter that specified some kind of validation function. These have been removed because the new registration templates can call the validation function for the custom class type directly. When a controller or property subclass defines the
ValidNode()
function (as a static member function), then it is automatically called to determine whether the controller or property can be applied to a particular node. Likewise, defining theValidPanelItem()
function in a mutator subclass will cause that function to automatically be called to determine what kind of panel item the mutator can be assigned to.
- Entity and locator registrations still work as they did before since they don't register new subclass types. Continue using the
EntityRegistration
andLocatorRegistration
objects to register these types.
- The perspective viewport in the World Editor can now render with full lighting, reflection, refraction, fog, and some effects. There is a new toggle button at the top of the editor window that switches between full lighting and bright ambient rendering. Geometries, lights, etc., can be moved around with full lighting turned on to see the immediate results of your changes.
- In the scene graph viewport, hidden nodes are now shown in a darker gray color. Nodes belonging to referenced worlds are shown in a reddish color.
- In the World Editor, the Layout page has been renamed to the Viewports page to avoid confusion with a future Layers page.
- The mouse wheel will now work at all times in the World Editor to zoom viewports, even when you're doing something else with the mouse button down.
- Pages in the World Editor can now be displayed on either the left or right side of the window. This can be changed in the Editor Settings dialog accessible from the Layout menu.
- The World Editor now displays a gizmo for selected nodes that shows the orientation of the node's local axes. The gizmo is shown as three arrows with colors red, green, and blue corresponding to the x-, y-, and z-axes, respectively. The gizmo is shown for one node in the selection at a time, and it can be iterated through the selected nodes by pressing the tab key. When the Select and Move tool is used, an arrowhead on the gizmo can be grabbed in any viewport and used to drag the node along its corresponding axis.
- In the next build, the gizmo will also have rotation handles, and it will be possible to display world-space and zone-space axes instead of object-space axes.
- Added a new Particle Systems page to the World Editor. This page displays a list of registered particle systems (see next item) and also contains tools for drawing emitter volumes. Particle systems now have a built-in connector of type EMIT that can be connected to an emitter volume. How the emitter volume is used depends on the particular particle system's implementation. Multiple particle systems can be connected to the same emitter volume.
- Application-defined particle systems can now be registered using the
ParticleSystemReg<>
class. Registered particle systems can be placed in a world using the World Editor.
- Particle systems can now be fully serialized, meaning that the state of all active particles is saved. If a custom particle type is defined, then it must implement
Pack
andUnpack
functions that save any custom state in addition to the base state saved with ,code>Particle::Pack.
- Added a new particle style called
kParticleQuad
that causes particles to be drawn as fully oriented quads instead of camera-facing billboards. Particle systems using this style must use theQuadParticle
structure to store particles. Thetransform
field of theQuadParticle
structure specifies the orientation of each particle as a quaternion.
- Added the
AddFarthestParticle()
function to theParticleSystem
class. This makes the newly added particle the first to render instead of the last, as is the case when theAddParticle()
function is called.
- Previously, it has been possible to render multiple fog spaces at once as long as they apply to different render targets, but each fog space had to be in a different zone. It is now possible to place multiple fog spaces in a single zone and have them all be considered for rendering (but still only into different render targets). This makes it a lot easier to add fog to areas that already contain a fog space for an underwater volume.
- The
DoorController
now exposes settings for three different sounds: one that plays when the door has fully opened, one that plays when the door has fully closed, and one that loops while the door is moving in either direction.
- The demo game module now defines the variable
$fov
to be the field of view for all cameras, in degrees. The game will clamp the value to the range[45,90]
.
- The String Importer tool will now translate \t, \n, and \r into tab, newline, and carriage return, respectively. As usual, a backslash can be obtained by using \\.
- The
TextBoxElement
interface class now starts a new line whenever a newline or carriage return character is encountered. The \n is recognized as a newline in the panel editor for text items.
- If an attempt is made to load a nonexistent model resource, the engine will now load a stand-in "missing" model instead of throwing an exception. The "missing" model is currently a yellow cylinder.
- The shot command will now pad out screenshot index numbers in filenames to four digits.
- Added support for 64-bit integers to the
String
class andText
namespace.
- Added a rendering callback to the
World
class. TheWorld::SetRenderProc()
function sets a callback function that is called right after the entire scene has been rendered insideWorld::Render()
, but before the Graphics Manager render target is changed back to the primary surface. This lets you render extra objects directly into the world's render target.
- Precached entity models will now be reloaded when a model resource is exported from the World Editor. This removes the need to quit and restart the engine when a model is changed. If the change occurs while clones of the model exist (perhaps because a world is running in the background), then they will not be replaced, but all new instances will use the new model resource.
- The Collada Importer tool has been updated to recognize additional material structures that are output by the 3DS Max exporter.