Open chamons opened 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.
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.
The project I'm playing with involves rotated cards being rendered.
The entry point for UiElement rendering:
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?