Linus-Mussmaecher / mooeye

UI library for the the ggez game engine.
MIT License
4 stars 1 forks source link

Unable to render UiElement with rotation #5

Open chamons opened 5 months ago

chamons commented 5 months ago

The project I'm playing with involves rotated cards being rendered.

The entry point for UiElement rendering:

    pub fn draw_to_screen(&mut self, ctx: &mut Context, canvas: &mut Canvas, mouse_listen: bool) {
        self.draw_to_rectangle(
            ctx,
            canvas,
            UiDrawParam::default()
                .target(Rect::new(
                    0.,
                    0.,
                    ctx.gfx.window().inner_size().width as f32,
                    ctx.gfx.window().inner_size().height as f32,
                ))
                .mouse_listen(mouse_listen),
        );
    }

Create the UiDrawParam based on no input, so I can't set the inner DrawParam rotation to something I control.

I could pretty easily add a fn draw_to_screen_with_rotation() but that doesn't seem to fit the rest of the API design.

Another option is to add an Option on the UiElement struct, add a with_transform setter, and then create the UiDrawParam based on that.

Thoughts?

Linus-Mussmaecher commented 5 months ago

UiDrawParam was only supposed to be the downstream communication between containers and their containing element, so not something you were supposed to access from the outside. I mostly thought about rectangular elements when creating this.

I think adding optional rotation to UiElement seems like the easiest choice, we could also add something like this to Layout as it will define were the element will end up. The biggest problem I see is that ggez does not really support rotated rectangles as a data type, only rotating them on drawing. So things like mouse collision and the calculation where the element is supposed to be will not be able to take this rotation into account without larger changes.

chamons commented 5 months ago

The biggest problem I see is that ggez does not really support rotated rectangles as a data type, only rotating them on drawing. So things like mouse collision and the calculation where the element is supposed to be will not be able to take this rotation into account without larger changes.

Hmm, the mouse collision thing could be rather annoying. I'm going to try another approach without rotation first, and double back here if it doesn't look right.