Closed bvssvni closed 4 years ago
The window is added as trait parameter because it permits setting stricter constraints on the implementation. For example, one can require W: AdvancedWindow
for a game, and this will work with any game manager that uses W: AdvancedWindow
.
I was thinking about depending on piston2d-graphics instead of adding a new Canvas
trait.
A minimal abstraction looks like this:
/// A simplified application interface for games.
///
/// A game might add additional constraints on the window for more features.
pub trait Game<W> where W: Window {
/// Render 2D graphics.
fn draw_2d(
&mut self,
_args: RenderArgs,
_draw_size: Size,
_c: &Context,
_g: &mut impl Graphics
) {}
/// Handle event.
///
/// This might handle customized render events, but this requires a custom window wrapper.
fn event<E: GenericEvent>(
&mut self,
_window: &mut W,
_e: &E
);
}
The problem is that some graphics backends uses extra fields.
It seems that simplification results in ending up almost where the design is today.
Decided to not add this. Closing.
For simple game applications, a more unified API could be added as an optional core module.
Here is a first draft: