search

hecrj / coffee

An opinionated 2D game engine for Rust
https://docs.rs/coffee
MIT License
1.07k stars 55 forks source link

Canvas ui element #113

Open dlight opened 4 years ago

dlight commented 4 years ago

For an ui element made out of graphics::Canvas, is it better to

  1. build a new ui::Canvas

  2. make it so that ui::Image can accept either graphics::Image or graphics::Canvas

  3. make it so that there's a Drawable trait that has fn draw<Q: IntoQuad>(&self, quad: Q, target: &mut Target), so that ui::Image accepts a &dyn Drawable trait object.

1 is the most logical given the way the library is currently laid out, but involves duplication. But I think ui::Image shouldn't care whether it's displaying an image or a canvas, so 2) sounds better.

3 seems like a big departure from the way the lib is currently designed, but I'm curious on why coffee doesn't provide such trait already.

hecrj commented 4 years ago

make it so that ui::Image can accept either graphics::Image or graphics::Canvas

Maybe we could make a Canvas::image(&self) -> Image method.

make it so that there's a Drawable trait that has fn draw(&self, quad: Q, target: &mut Target), so that ui::Image accepts a &dyn Drawable trait object.

ui::Image needs to also know the drawable dimensions. There are some resources where performing that kind of query isn't straightforward.

seems like a big departure from the way the lib is currently designed, but I'm curious on why coffee doesn't provide such trait already.

Well, it's just that I do not think there is a trait that fits all the different drawable resources. For instance, Mesh and Font do not take an IntoQuad.

I also try to avoid adding abstractions just because they may seem nice. I like to have a couple or more use cases first, and I haven't needed such an abstraction yet!