|
|
|
using gaemstone.ECS;
|
|
|
|
using static gaemstone.Flecs.Pipeline;
|
|
|
|
|
|
|
|
namespace gaemstone.Flecs;
|
|
|
|
|
|
|
|
[Module, Path("/flecs/pipeline")]
|
|
|
|
public static class SystemPhase
|
|
|
|
{
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
public struct PreFrame { }
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
/// This phase contains all the systems that load data into your ECS.
|
|
|
|
/// This would be a good place to load keyboard and mouse inputs.
|
|
|
|
/// </summary>
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<PreFrame>]
|
|
|
|
public struct OnLoad { }
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
/// Often the imported data needs to be processed. Maybe you want to associate
|
|
|
|
/// your keypresses with high level actions rather than comparing explicitly
|
|
|
|
/// in your game code if the user pressed the 'K' key.
|
|
|
|
/// </summary>
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<OnLoad>]
|
|
|
|
public struct PostLoad { }
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
/// Now that the input is loaded and processed, it's time to get ready to
|
|
|
|
/// start processing our game logic. Anything that needs to happen after
|
|
|
|
/// input processing but before processing the game logic can happen here.
|
|
|
|
/// This can be a good place to prepare the frame, maybe clean up some
|
|
|
|
/// things from the previous frame, etcetera.
|
|
|
|
/// </summary>
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<PostLoad>]
|
|
|
|
public struct PreUpdate { }
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
/// This is usually where the magic happens! This is where you put all of
|
|
|
|
/// your gameplay systems. By default systems are added to this phase.
|
|
|
|
/// </summary>
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<PreUpdate>]
|
|
|
|
public struct OnUpdate { }
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
/// This phase was introduced to deal with validating the state of the game
|
|
|
|
/// after processing the gameplay systems. Sometimes you entities too close
|
|
|
|
/// to each other, or the speed of an entity is increased too much.
|
|
|
|
/// This phase is for righting that wrong. A typical feature to implement
|
|
|
|
/// in this phase would be collision detection.
|
|
|
|
/// </summary>
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<OnUpdate>]
|
|
|
|
public struct OnValidate { }
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
/// When your game logic has been updated, and your validation pass has ran,
|
|
|
|
/// you may want to apply some corrections. For example, if your collision
|
|
|
|
/// detection system detected collisions in the <c>OnValidate</c> phase,
|
|
|
|
/// you may want to move the entities so that they no longer overlap.
|
|
|
|
/// </summary>
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<OnValidate>]
|
|
|
|
public struct PostUpdate { }
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
/// Now that all of the frame data is computed, validated and corrected for,
|
|
|
|
/// it is time to prepare the frame for rendering. Any systems that need to
|
|
|
|
/// run before rendering, but after processing the game logic should go here.
|
|
|
|
/// A good example would be a system that calculates transform matrices from
|
|
|
|
/// a scene graph.
|
|
|
|
/// </summary>
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<PostUpdate>]
|
|
|
|
public struct PreStore { }
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
/// This is where it all comes together. Your frame is ready to be
|
|
|
|
/// rendered, and that is exactly what you would do in this phase.
|
|
|
|
/// </summary>
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<PreStore>]
|
|
|
|
public struct OnStore { }
|
|
|
|
|
|
|
|
[Entity, Add<Phase>]
|
|
|
|
[DependsOn<OnStore>]
|
|
|
|
public struct PostFrame { }
|
|
|
|
}
|