RFC: Refactor context

[msiglreith]

Motivation

The context struct is a large struct containing different subsystems (

amethyst/src/context/src/lib.rs

Lines 53 to 65 in ea43b89

	/// Contains all engine resources which must be shared by multiple parties, in particular `Renderer` and `Broadcaster`.
	/// An `Arc<Mutex<Context>>` is passed to every `Processor` run by the engine and a `&mut Context` is passed to every `State`
	/// method.
	pub struct Context {
	// pub video_context: VideoContext,
	pub renderer: Renderer,
	pub asset_manager: AssetManager,
	pub input_handler: InputHandler,
	pub broadcaster: Broadcaster,
	pub delta_time: Duration,
	pub fixed_step: Duration,
	pub last_fixed_update: Instant,
	}

), which is passed as Arc<..> to the different processor requiring to lock the whole context.

Proposal

Split the context into the separated subsystems + a new context (with delta_time, timestep, ...).
The subsystems are added as resources to the world, allowing a more fine-granual locking and removes the need of a global object passed around trough the whole engine.

Open questions

How does this influence the entity-component system in terms of scheduling?
Will we only have a single world in the future, if not how should the resources be handled?

[Aceeri]

I'm pretty sure resources in specs behave exactly the same as components, splitting it up into subsystems just means less blocking between systems to get access to the context (when they might not use it).

I think it is safe to assume we will only have one world, I'm not sure what benefits you would get by having multiple.

[Aceeri]

To add to this, I'm thinking maybe we should move the context out of a sub-crate and into the core library of amethyst (similar to the ecs processors and such), since it is highly interconnected with the other sub-crates. Thoughts?

[msiglreith]

Seems to be fixed by #133.