Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clickable area according to bitmap #24

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

nbrr
Copy link
Contributor

@nbrr nbrr commented Sep 2, 2020

Example draft for #22: it displays the cone pine image and moves it randomly when one tapes on the non-transparent area. Swipe exits. I did it quick & dirty as an example to see how it works out, it needs be abstracted.

Also relevant to #21: indeed we can just use the move semantics; I also had in my mind that maybe one could want to manipulate the universe outside the callback but the way it is now is not limiting and I can't come up with a scenario interesting enough for now.

Also relevant to #18: introduced a couple of fixes to panics introduced by the switch to u32 pixels.

@nbrr
Copy link
Contributor Author

nbrr commented Sep 2, 2020

Throwing in ideas for abstraction.

trait InteractiveObject<T> {
    fn try_activate(&self, swipe: Swipe) -> bool;

    fn action(???) -> T;

    fn render(&self, canvas: &mut Canvas);
}

struct SimpleTappableObject{
    width: usize,
    height: usize,
    /// Where the object is meant to be placed
    origin: (usize, usize),
    /// Interactive points
    bmap: BlitMap,
    /// Visual rendering
    visual: Canvas,
    /// Actions to be performed when touched
    action: Fn(???) -> T
}

impl InteractiveObject<T> for SimpleTappableObject {
    fn try_activate(&self, swipe: Swipe) -> bool {
        // - check that the swipe is a tap
        // - check that the tap hits the bmap right
    }

    fn action(???) -> T {
       // do that actions
    }

    fn render(&self, canvas: &mut Canvas) {
        // draw on the canvas
    }
}

struct ComplexTappableObject<T> {
    origin: (usize, usize),
    simple_objects: Vec<SimpleTappableObject>,
}

impl InteractiveObject<T> for ComplexTappableObject {
    // similar but different action for different parts
    // maybe force the simple objects to have the same origin/bmap?
}

The d-pad would be composed of 4 simple tappable objects, corresponding to each branch of the d-pad.
The d-pad can thus be manipulated as one object with 4 possible actions.

Maybe Layers could bear such object and non-interactive objects (just stuff with a render method), and we would flatten by drawing in some order. Possible issues: overlapping interactive objects, overlapping objects in the same layer (could check that bmaps are disjunct).

@nbrr
Copy link
Contributor Author

nbrr commented Sep 11, 2020

@richardanaya the example is starting to take form. It displays a d-pad that moves the pine image. It lags a bit some time when you spam tap it, I haven't pin pointed where the delay is coming from, looking at the debug log it doesn't seem to be happening at a specific moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant