Functions | |
void | pglRegisterCustomPrimType (GLenum primType, pglU64_t requirements, pglU64_t rendererReqMask, int mergeContiguous) |
Register a new primitive. More... | |
void | pglEnableCustom (pglU64_t flag) |
Enable a custom attribute/state change. More... | |
void | pglDisableCustom (pglU64_t flag) |
Disable a custom attribute/state change. More... | |
void | pglUserRenderContextChanged () |
void | pglBeginRendererDefs () |
Call this before registering any renderers. More... | |
void | pglRegisterRenderer (void *renderer) |
Register a custom renderer. More... | |
void | pglEndRendererDefs () |
Call this after registering custom renderers. More... | |
const char * | pglGetCurRendererName () |
Returns the name (string) of the current renderer. More... |
The ps2gl code that runs on the ee core is just a large, ugly state machine -- all of the "real" work is done in the renderers. There are currently a dozen or so internal renderers which handle different types of geometry, lighting, texturing, etc. Most of the internal renderers implement some case that none of the others can do, but a few are specializations of more general renderers that implement a commonly encountered case more efficiently that the general renderer can. Using the functions described below, an application can define custom renderers or override existing ones.
But first, an explanation of how ps2gl chooses renderers is necessary. ps2gl keeps a bitfield of capabilities that a renderer must provide to be chosen to render. This bitfield is called the "renderer requirements" and describes things like lighting, texturing, prim type, shading type, etc. Each renderer also keeps a corresponding bitfield describing the capabilities that it provides, called its "capabilities." Each bit means that the corresponding capability is required (or provided, in the case of a renderer). Consider the "lighting" bit. This bit is set when glEnable( GL_LIGHTING ) is called and changes the renderer requirements, causing ps2gl to look for a new renderer the next time geometry is rendered. Each renderer's capabilities will be compared to the current renderer requirements, and the first renderer that meets all the requirements is chosen. In this example, only a renderer that can do lit geometry will be selected.
Renderers are searched in the order they were registered, application-defined renderers first. This means that specialized renderers should be registered before general ones. It also means that to override a default renderer, an application need only register a renderer that provides the same capabilites (or a subset).
Implementing a custom renderer whose purpose is not to override a built-in renderer implies defining custom prim types and/or properties, for which the upper 32 bits of the renderer capabilities/requirements are reserved. See the function documentation below for more details.
For more information on implementing a renderer, see the file "renderer.h" which defines the CRenderer interface. (Sorry, but the renderer needs to be a cpp class.) The best examples are the default renderers, so take a look at linear_renderer.* and base_renderer.*.
|
Call this before registering any renderers.
Definition at line 736 of file renderermanager.cpp. |
|
Disable a custom attribute/state change. Call this to disable the corresponding bit(s) in the renderer requirements bitfield. The lower 32 bits should be zero.
Definition at line 422 of file gmanager.cpp. |
|
Enable a custom attribute/state change. Call this to enable the corresponding bit(s) in the renderer requirements bitfield (see above). The lower 32 bits should be zero.
Definition at line 409 of file gmanager.cpp. |
|
Call this after registering custom renderers.
Definition at line 759 of file renderermanager.cpp. |
|
Returns the name (string) of the current renderer. You'll need to call glFlush() to be sure that the renderer is in in sync. Probably doesn't make much sense to call this inside of a glBegin/glEnd pair.
Definition at line 771 of file renderermanager.cpp. |
|
Register a new primitive. After registering a primitive with this call it can be used anywhere a normal primitive can be used (glBegin, glDrawArrays, etc.). Defining a new primitive usually implies writing a renderer to go along with it.
Definition at line 395 of file gmanager.cpp. |
|
Register a custom renderer. The maximum number of custom renderers is indicated by PGL_MAX_CUSTOM_RENDERERS.
Definition at line 749 of file renderermanager.cpp. |
|
Definition at line 429 of file gmanager.cpp. |