Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits)

The rect module (which, for those unfamiliar, is included in the "All About Draggable" example deck) includes functions like rect.overlaps[] and rect.inside[] for manipulating "rectangles", which can either be a dictionary containing pairs with the keys "pos" and "size" or any Decker interface value that happens to have those fields- widgets, for example.

The pointer interface has a .pos field, but no .size field. Using an invalid index into an interface type returns 0, so the pointer interface kinda fulfills the contract and sort of works as an argument to these utility functions (as if it were a rectangle of size 0), if only by coincidence/accident.

I whipped up a little test, and sure enough this seems to work fine given an animated button:

on view do
 field1.toggle["solid" rect.inside[pointer button1]]
end


(Note that "tooltips" like this won't work properly on multitouch devices, since such input devices do not update the pointer position while a user's finger happens to be hovering above the display; this is why Decker doesn't have any sort of tooltip functionality built in.)

The same script body ought to work just fine from a centralized event pump rather than having every object with a tooltip be individually animated. I don't really follow what you mean in terms of the rect module "detecting the widget type".

thank you for the answer! this already opens up a lot of possibilities, actually.

what i meant was if there was a way of having, for example, an animated field widget that displayed text whenever the pointer went over a button. and i figured the way to do this was such field having something like:

on view do
 if rect.overlaps[pointer (((any button)))]
  me.text:"pointer over some button"
 else
  me.text:"pointer over any other thing"
 end

(it just occurred to me that i can name a group of widgets that are buttons and do this, but i'm thinking of a less manual approach)