Kokos Posted August 6, 2015 Share Posted August 6, 2015 Hey, I'm trying to build a container with scrolling content. How I've done this is I've created a container, this container has a mask of the same size and then the content is a sprite with drag inputs enabled.The content sprite doesn't show outside of the container because of the mask, but I can still drag it by clicking outside of the container. Here is an image to illustrate what I'm trying to achieve: (container in gray, dragsprite in red, masked parts of dragsprite in faded red) So my problem is I can still click the faded red parts to drag the sprite, even though I can't see them. I've made a quick fix now by having another sprite outside of the container with input enabled and a higher priorityID, but this is a very hacky solution as the outside sprite doesn't need inputs. Is this a limitation of the sprite inputhandlers, or am I missing something? The only real solution I see now is writing my own drag script and handlers (which is fine, but more work). tips4design 1 Link to comment Share on other sites More sharing options...
Tom Atom Posted August 6, 2015 Share Posted August 6, 2015 you are probably using sprite.inputEnabled...? This makes the touch area as big as sprite by default. But you can change it with sprite's hitArea property. It can be any object implementing HitArea interface like PIXI.Circle/Ellipse/Rectangle/Polygon you will probably have to change hitArea's position to achieve what you need... Link to comment Share on other sites More sharing options...
Kokos Posted August 10, 2015 Author Share Posted August 10, 2015 Awesome! I have to reposition the hitArea every time the sprite is dragged, but this is a pretty good fix. Thanks! Link to comment Share on other sites More sharing options...
wayfinder Posted August 10, 2015 Share Posted August 10, 2015 How about making the "window" the click target? And then instead of making it draggable, you move the content around according to the user's inputs. Link to comment Share on other sites More sharing options...
Kokos Posted August 10, 2015 Author Share Posted August 10, 2015 Yeah, a different solution would be not using the sprite input handlers, but write my own event handlers that work on the container but move the other sprite. However then i'd have to rewrite a bunch of code that's already implemented in sprite inputs.I was already doing position logic in my update because in the actual game I'm dragging multiple sprites, not one. Which means that I have one draggable sprite that updates the other sprites positions according to his own. Right now I want to move into testing quickly, so I just wanted something that would work and be fast to implement. I might end up writing a proper solution at some point. Link to comment Share on other sites More sharing options...
wayfinder Posted August 10, 2015 Share Posted August 10, 2015 it's not a bunch of code, it's like 5 lines i did the same thing in my current project. you set a "dragging" variable on mousedown and record the current mouse position, then in a mouseMove handler, if the variable is set, you move the content by the difference between the current mouse pos and the recorded position, and set the current pos as the new drag startpoint. on mouseUp, you unset the dragging flag. i think that about covers it. drhayes 1 Link to comment Share on other sites More sharing options...
Recommended Posts