113 lines
3.7 KiB
Plaintext
113 lines
3.7 KiB
Plaintext
This file describes the program logic and organization. It holds a focus on data types and classes.
|
|
|
|
,,,,,,,,,,,,,,,,,,,,,,,,
|
|
Program Organization
|
|
§§§§§§§§§§§§§§§§§§§§§§§§
|
|
To begin with, RtB is governed by a state machine, individual states, and sub-states (modal dialogs/windows). The state machine, as run by the main loop, is as follows:
|
|
|
|
1. Check states for destroy/clean-up flags
|
|
a. destroy all states with said flags
|
|
2. For each Event,
|
|
a. send down the event to each state's onEvent(event)
|
|
1. if State eats event, continue to the next Event
|
|
3. For each State,
|
|
a. call onThink, if State blocks, break
|
|
4. For each State,
|
|
a. call onDraw, if State blocks, break
|
|
|
|
Alternatively..
|
|
|
|
[ State Machine ]
|
|
[ governs State ]
|
|
[ event + think ] --- creates RenderSet
|
|
|
|
|
[ Render System ] <-----+
|
|
[ renders all ]
|
|
[ "RenderSet"s ]
|
|
|
|
The State Machine governs all event handling and logic, while the Render System governs all rendering. Within the Render System, you have RenderSets which, in turn, have RenderObjects:
|
|
|
|
RenderSet {
|
|
char *name; // (or std::string) ex. "Voxel Models"
|
|
int mode; // bitflag, 0 = normal, 1 = hide
|
|
std::vector <RenderObjects>;
|
|
GLuint program; // Shader Program to use
|
|
}
|
|
|
|
What we want for Render Objects:
|
|
World Objects:
|
|
Rendering of textured plane (flat image)
|
|
Rendering of full textured 3d model
|
|
Rendering of textured voxel model
|
|
UI Objects:
|
|
Textured plane (flat dialog, texture of text)
|
|
|
|
RenderSets should be contained in a RenderScene, which would be something akin to:
|
|
|
|
RenderScene {
|
|
char *name; // (or std::string) ex. "Game"
|
|
RenderCamera *camera; // ptr to RenderCamera object
|
|
GLuint context; // framebuffer object to render the scene to
|
|
std::vector<RenderSet> sets;
|
|
}
|
|
|
|
During the render call, the current RenderCamera defines both the position and orientation of the view.
|
|
|
|
RenderCamera {
|
|
char *name;
|
|
Vec3 x, y, z; // OR should it be a quaternion?
|
|
int mode; // perspective, orthogonal
|
|
GLuint target; // framebuffer target?
|
|
RenderView view; // alt to ^
|
|
}
|
|
|
|
RenderView {
|
|
GLuint program; // shader program to render with
|
|
GLuint target; // fbo/texture target
|
|
unsigned int w, h; // width and height of view (also of texture!)
|
|
int x, y; // x and y, in terms of render start on screen
|
|
}
|
|
|
|
RenderScenes are, potentially, contained in a layered system, of which there are the following categories in order of rendering:
|
|
|
|
1. Terrain Layer (terrain, obv.)
|
|
2. Game Layer (models, tokens, etc.)
|
|
3. Game Overlay (hp, arrows, etc.)
|
|
4. Dialogs (mini character sheets, etc.)
|
|
5. Windows (character sheets)
|
|
6. UI (menu access, etc.)
|
|
7. Notification (modal dialog boxes, usually d/c, quit, etc.)
|
|
|
|
These render layers could be implemented as such:
|
|
* Basic array with enums for each layer
|
|
* std Vector
|
|
* Double-linked list
|
|
|
|
These layers simply provide an ordering to rendering.
|
|
|
|
In brief:
|
|
RenderObject defines a specific object in the world
|
|
RenderSet defines a common group of RenderObjects to be rendered
|
|
RenderCamera defines the positions and orientations we render
|
|
RenderScene defines the world to be rendered and where to render to
|
|
|
|
So sort of:
|
|
RenderScene
|
|
RenderCamera
|
|
ptr to RenderView
|
|
RenderSet(s)
|
|
RenderObject(s)
|
|
RenderView
|
|
|
|
The Render call would be:
|
|
* for each RenderScene
|
|
* for each RenderCamera
|
|
- camera = RenderCamera
|
|
* for each RenderSet
|
|
- set render output to camera's fbo target
|
|
* for each RenderObject
|
|
- if out of view, continue
|
|
- get MVP from camera, apply, and render
|
|
* for each RenderView
|
|
- render FBO to screen, additive? multiply?
|