Is it possible to test for overlapping objects / images?
I am working on developing a way to use images as cursors, and one issue I am having is the [pict] object attached to the mouse is blocking hover and mouse calls.
So another approach is to test when the cursor image is overlapping an object, but to do that I would need to be able to retrieve an object by coordinates. So I thought a good place to start was to see if Max had any collision detection functionality.
In Pure Data, you have a [cursor] object that can change the appearance of your mouse pointer. If i wanted to achieve somethign similar as what you're trying, i would try to port tha tobject into MaxMSP ; rather than workaround by dragging a [pict], which seems cpu intensive and seems it will lead you into numerous problems...
Weeeell, apparently someone did it already ! http://arts.lu/roby/index.php/site/maxmsp/rs.cursor
Cool, thanks for the quick response. I took a break to work on some other things, but will jump back on this soon and try your solutions.
@Vichug,
I looked at your responses. Currently I do not have a mac available to test the work around, but I do have a question. I have never ported anything to Max before, so I would I do that? And furthermore, how would that lead to me changing the mouse cursor? Are you using another language to change the cursor?
Ah well.
I'm not sure, but i guess the puredata external works on both macos and windows, so you could get an idea how it works. It is basically an object inside PureData to which you send messages ; unfortunately it works only with a set of predefined Tcl/Tk native cursor pngs (Tcl/Tk is the graphic frontend used by PureData). You would find it difficult to give your own shape to your cursor anyway.
I didn't know you were on Windows, it might be more difficult for you then... cursor are something that seem very platform specific... you would need the source of rs.cursor object, which i'm not sure Roby Steinmetzer is willing to give, and porting a max external from max to windows can range from super easy to nearly impossible/having to rewrite thigns from scratch, and if you don't have experience in programming (i mean textual languages), it might not be worth it, at second thought... theeeen i would suggest going on your previous way, sorry.....
aaand... to go on to your previous way, if i had to do it, i would rather have one pixel of the cursor (the active one) over your image than trying to detect collisions, for which MIB's suggestion is good, but which would be complicated to implement. But, i don't know...
And if i refer to your other older topic, you might want to substract (or is it add ? some amth to do anyway) patcher's coordinates (which you can get using [thispatcher]) to the current mouse position in order to have something more accurate. Scrolling things would still be a problem though !..You could also have you picture in a subpatcher floating window, without borders/menubars, you could then move it relatively to screen coordinates directly (once again you'll get those coordinates with [thispatcher]).
@Vichug, thanks for the reply. Yeah, we actually are building the application for Mac and PC. There is no scrolling either.
Hmmmmm, your last suggestion sounds interesting, creating the cursor as a separate window. This would involve more calculation and development, or rather using the different mode of the [moustestate] object, which I planned on eventually (instead of mode 2, it would be mode 1). But it sounds like there aren't many options.
I will try and "fake" the cursor experience :P. I will post my results when I have them.
@Vichug,
I have created a custom cursor that is a separate window that follows the mouse position, but I am running into the same issue as before where the cursor blocks mousestate and hover objects from firing. Also, I tried using a [subpatcher] inside my patcher and re-positioning to the moue cursor but it still occurred. Any suggestions?
I updated the window each time I move the moue with the following line.
window size $1 $2 $3 $4, window front, window exec
which I pass to the [thispatcher] object, where the variables are the correct mouse coordinates
EDIT: I bypassed this issue by placing the window 1 pixel off the x and y position of the mouse cursor position. I believe it the button is big enough and you move the mouse really fast, the window has a change of blocking the hover objects. and I believe I may run into trouble with the rolled over cursor cause it will most likely be a pointing hand and for a smooth user experience, that image should be overlapping the mouse position.