Changelog: - Refactor the EC header files to put struct in more sensible locations: - Sprite and Particle Emitter + Configs are now assets, as they should be - Components type are now unsigned int, thus it is not sensitive to any component enums - Components enums are now pure index store. There are two sets of components: Basic for engine use, Extended for game-specific ones - Component memory pools are now defined on outside of engine. Majority of the components will be game-specific, so it should be on the game to define the components and the mempools for all of them. |
||
---|---|---|
.. | ||
sc | ||
AABB.c | ||
AABB.h | ||
CMakeLists.txt | ||
EC.h | ||
README.md | ||
actions.h | ||
assets.c | ||
assets.h | ||
collisions.c | ||
collisions.h | ||
engine.c | ||
engine.h | ||
engine_conf.h | ||
entManager.c | ||
gui.c | ||
gui.h | ||
mempool.c | ||
mempool.h | ||
particle_sys.c | ||
particle_sys.h | ||
raygui.h | ||
rres.c | ||
rres.h |
README.md
I suppose need to write these down to remind myself
Scene Management
The engine provides a generic Scene struct that should be embedded in a another struct, which provide scene-specific data.
As such, the engine will manage pointers to Scene struct. When using the engine, it is expected to provide the a pointer to the embedded Scene struct to the engine for scene management. All scenes should be declared upfront and an array of the Scene pointers should be provided.
What is a scene?
A scene is a data struct containing these major fields:
- Entity Manager
- Input-Action Map
- Systems
- Particle System
- plus other fields
These fields exists to perform the scene update loop of:
- Input handling
- Scene Update
- Scene Rendering
Scene State
In this implementation, there will always be a 'root' scene at any given time. The program ends if there is no 'root' scene. A scene change/transition occurs when this 'root' scene is changed to another scene.
A scene has an active state and a render state.
- Active: Should it run its scene update procedures?
- Render: Should it be render? Hence, it is possible to have a scene updated but hidden, or a paused scene (not updated but rendered).
There is also a 'focused' scene. This is the scene to intercept inputs and run its action update procedure. There can only be at most one such scene. Two or more scenes are not allowed to receive inputs in this implementation. It is possible to have zero focused scene.
Scene Hierachy
A scene can have multiple children scenes but can have only one parent scene. This implemented as a intrusive linked-list.
The implementation assumes a single-threaded environment for simplicity. The scene update travesal logic is as such:
- The current scene first
- If the scene has a child scene, traverse that child first.
- If the scene has a next scene, traverse there then.
- Repeat from (1) until no possible scene is traversable