Hover effect when dragging

[trevb]

Hi all,

I'm pretty new to this framework and have been failing to come up with a viable solution - was hoping you guys could help me out?

I am building an Phaser application where I have the ability to drag a sprite over the top of another sprite and drop it onto the sprite below it, at which stage my code will create a relationship with the dropped sprite and the sprite it was dropped on. I am not using any physics for this. This should add some context to the problem but the 'drop' is not the question I want answered.

Whilst dragging over the sprite I would like to alter the dragged sprite's scale to show the user that it is being detected as hovering over something it can drop into.

I could iterate through the sprites on screen and check whether the coordinates of the dragged sprite hit another sprite but that would be terribly inefficient to put in the onDragUpdate function.

I'm looking for an alternative where I can raycast (or similar) from the sprite's x/y drag position from the dragged sprite downwards and see if it hits another sprite. Any ideas as the docs are a bit thin in this area?

I've created a JS Fiddle to help demonstrate: https://jsfiddle.net/trevburley/3ymgadvo/9/

Many Thanks - Trev

[samid737]

Your suggestion to iterate trough the white blocks seems the most straightforward approach to me. Why would it be terribly inefficient? You could use isDragged in your main update function as a trigger if you want to avoid using onDragupdate.

If you plan on using raycasting to check for collisions, then you will still need some sort of way to identify which object you are colliding with, because you have randomness involved in your problem. If you had a fixed spacing between white blocks, then you could locate and identify a block by doing the math. To me it seems inescapable that you will need to iterate trough your white block to check for collision.  

There might be a very sneaky way to approach the scaling of your object, but this is in a very limited scenario and is super experimental (WEBGL only):

Here you are reading the pixel color of the pixels surrounding your mouse/sprite. If either one of the pixels below,above,left or right from your mouse/sprite is white, then you are approaching a white block and you can scale. It does not seem to work for white blocks in the upper left and right corner ( the buffer data does not match the pixel color data) , so its not fully functional, but you might be able to work something out. You will also have to consider performance carefully IF you think about doing something like this. Note that you can also read the alpha value of the pixel instead of the RGB values. This method does not tell you WHICH box you are colliding with, so you have to come up with a solution for that.

The example also includes a line that is computed according to your mouse movement speed. It can be used as a basis for raycast checking. The only part you have to implement would be something like:  

whiteblocks.foreach(function(block){
if (line.intersect(line,block)){
 //highlight block, prepare your red block for scaling, since it is approaching the block
}
}

You could also (an easy way out) add a physics body to each white block and use collision checking between a whiteblock group and the red block:

https://phaser.io/examples/v2/arcade-physics/sprite-vs-group

 

[trevb]

Thanks for your feedback samid737, I'll have a look into the options you've given me!

Cheers - Trev

[samme]

I don't think you have to check for overlaps in the drag function. You can just check the normal way, via update → physics.arcade.overlap, flag any overlapping sprites, then look for the flag in onDragUpdate.

[samid737]

@samme is right you can do your checking in the update function instead. Another possibility, but even more costly:

https://phaser.io/examples/v2/input/pixel-perfect-click-detection

[trevb]

Cheers guys, I couldn't use WebGL as it seems to push the Macs a bit hard (Retina displays) although it's fine on my PC so I opted to group the dropzones so that I can iterate through them quickly on drag update and it seems to have done the trick. I don't like putting loops in update functions personally but it seems it was necessary.

Trev