jacque wrote: ↑Tue Dec 26, 2017 11:37 pm
MouseMove sends the current coordinates as parameters, so the engine has already done the work much faster than we can. Checking the coordinates within a line of script is more expensive...
<sic>
... gets the mouse location for an intersection test, then gets the location a second time when calculating the final position. So, two mouse checks plus another call for an intersection check. Using mouseMove requires no calls for the mouse state.
<sic>
That said, using mouseStillDown is still more efficient than a repeat loop which would be completely blocking.
Now that is good to know, I hadn't come across it previously, and didn't think about it while coding it up. It does explain a few things though now that I think on it.
richmond62 wrote: ↑Tue Dec 26, 2017 11:55 pm
Works on the basis that the thing that is being dragged is 10 pixels wide.
This doesn't care what size the thing that is being dragged is
Yup, just came across this particular information today while exploring some of the presents you sent me
In previous languages, I'd more likely have coded that "the width of me /2", eliminating the size measuring part of it.
The test for the mouse position was solely to find out if it was inside of the button in the first case, as opposed to somewhere generally in the area or on the card. IF I were just trying to move the button to where the mouse was, it would have been a single mouse down event, but the items would have been the same.
With the additional condition Da_Elf put of only moving right, I would have changed the if/then to simply move the button if the mousedown had been in the rect of the graphic farther right than the right of the button.
What you have there looks pretty slick though