In response to Kuraudo
Kuraudo wrote:
So you're saying that you can use MouseEntered() in such a way that if you move the mouse around without entering/exiting a tile, it will generate updates to the mouse coordinates?

In the video, if you moved the mouse up two pixels, the character followed. In DM---as far as I'm aware---you would have to move it up 32 pixels (or whatever the atom size is, I guess) to generate the next message. That doesn't model the mouse-following interaction of the video at all.

MouseEntered() wouldn't work well. For one, it's laggy if you move your mouse quickly. Second, like you said, if your game is tile-based, you would have to move the mouse [tile size] pixels to call MouseEntered. I said [tile size] because if you really want to, you CAN use MouseEntered with increased precision (e.g. see the Paint program by XxDohxX (I forget exactly how he spells his name)) but then you run into the lag problem. I ran into the same problem when testing automatic weapons in Vengeance 56; the position updates by MouseEntered were so slow that they lagged the whole game even in single player mode.

My recommendation would be a built-in proc to get the over_location, pixel_x, and pixel_y of the cursor. Doing so, you could build the proc into a for() loop to assay the cursor position at any given time (e.g. every tick, every time a shot is fired, etc.). I'm not aware of a proc that can do this at present.
In response to Kuraudo
Kuraudo wrote:
So you're saying that you can use MouseEntered() in such a way that if you move the mouse around without entering/exiting a tile, it will generate updates to the mouse coordinates?

I actually created a system that would do this, albeit, not using MouseEntered(). Problem is, it's just as slow as the other mouse related functions.

Another, terrible, workaround would be to use a world.icon_size of 1. That would be fun.
Page: 1 2