Mouse Position

by Forum_account
Mouse Position
Provides a way to get pixel-precise mouse coordinates.

new library - Mouse Position

Page: 1 2
ID:117686
 
Aug 26 2011, 6:52 pm
This library creates the client/MouseUpdate() proc, which provides the developer with mouse coordinates as the player moves the mouse. This gives greater precision than the current mouse procs - you can get the pixel coordinates of the mouse, but only when an event happens.

The values passed to the MouseUpdate() proc are the components of a screen_loc string so you can easily update the positions of objects based on these values. For example:

client
    MouseUpdate(tx, px, ty, py)
        mob.crosshair.screen_loc = "[tx]:[px - 16],[ty]:[py - 16]"


This is done using two screen objects that capture mouse events. It doesn't use JavaScript so it should work for all clients.

This library is based on ideas from these forum posts. Hopefully this will become obsolete some day because there's a lot of room for improvement. It seems to work ok, even with the default tick_lag (though there's a substantial difference even when going from 10 fps to 15). However, if the player is moving the mouse while also moving (using the arrow keys) it doesn't seem to update nearly as well.
Aug 26 2011, 8:34 pm
Very nice. Yeah, a checkered pattern with two screen objects might be the only way to do it as of right now. I been contemplating about mouse control and how to properly handle it. I might use your library or aid in research of it.

If I find anything, I'll make sure to share data obtained from such research and experimentation.
Aug 27 2011, 12:43 am
Hey, maybe this could help Bravo1 on Tanx? :D
Aug 27 2011, 1:42 am
Okay, so, not only did I just get to upgrade my system to Win 7 Ult, but now I'll have a full working mouse detection for Tanx?

My day went from utter shit to best ever. (Utter shit was due to about 12 hours straight of nothing but installation issues)
Aug 27 2011, 1:58 am (Edited on Aug 27 2011, 2:05 am)
Yusuke13 wrote:
Hey, maybe this could help Bravo1 on Tanx? :D

I hope so. Unfortunately the library doesn't perform well when the player is pressing keys while moving the mouse. I'm not sure why (seems like a BYOND bug), so maybe the staff will improve this library or add the feature.

The library works better with a higher framerate, so maybe that'll make up for its problems. Also, in Tanx, I believe the turret slowly turns to face the mouse cursor, so it might look ok even if the mouse position isn't updated perfectly.

Edit:
It might be my imagination, but it seems to work better with the Pixel Movement library because the keyboard macros are for key press and release, not repeat. If, in the demo that comes with the library, you stand against a wall and hold the arrow key to move towards the wall, you're still providing input (the key is repeating) but you're not moving. If you move the mouse at the same time it won't update nicely.
Aug 27 2011, 2:05 am
It should work fine for Tanx, I don't need the mouse to update perfectly, I just need it to update consistently, which this library seems to do fairly well.
Aug 27 2011, 2:11 am
I'm not sure how you handle things now so I don't know how similar or different this is, but what I'd do is create a background loop that turns the turret towards the last known mouse position. Even if MouseUpdate() isn't called every tick, the turret will be turned every tick by this other loop.
Aug 27 2011, 2:13 am
Yeah, I have the turret turning using angle and next_angle to figure out where to turn, and I'm also using movement() to turn the turret when necessary. At least, that's how it works for the AI. Modifying it so that clients do the same won't be an issue though. =P
Aug 27 2011, 2:25 am
It looks like this is a BYOND bug that's been fixed before but is back again, so I submitted a bug report.
Aug 27 2011, 3:06 am
I hope you get this stuff fixed, Bravo. I want to feature that shizz.
Aug 27 2011, 4:10 am
Forum_account, stop making demos on how to do the more complexed stuff... =(.....

I am somewhat pleased to see I'm not the only one to figure out the way of forcing BYOND to update the mouse without creating a BUNCH of invisible objects. =)..
Aug 27 2011, 4:31 am
Nvm, spoke too soon(however your way is much better than mine. I changed an object's loc back and forth to force mouse update. Which would happen every world tick).
Aug 27 2011, 4:45 am
I thought about making a screen object that follows the mouse cursor, but it'd have to follow it perfectly for it to work right. Once the mouse moved too far from the screen object it wouldn't work. Though, this would have the benefit of not having to draw two full-screen, partially transparent screen objects. I'm sure some users with slow graphics hardware might not be able to handle drawing full-size screen objects.

Forum_account, stop making demos on how to do the more complexed stuff... =(.....

Why? =)
Aug 27 2011, 4:50 am
I say stop making demos on the more complexed stuff because your demos are too easy to use! I have a thing about hating it when people use demos to make games XD...
Aug 27 2011, 5:35 am
Ss4toby wrote:
I have a thing about hating it when people use demos to make games XD...

Well, I have a thing about people *not* using demos or libraries, then working on a game and never finishing it =)
Aug 27 2011, 2:08 pm (Edited on Aug 27 2011, 2:15 pm)
Forum_account wrote:
It might be my imagination, but it seems to work better with the Pixel Movement library because the keyboard macros are for key press and release, not repeat. If, in the demo that comes with the library, you stand against a wall and hold the arrow key to move towards the wall, you're still providing input (the key is repeating) but you're not moving. If you move the mouse at the same time it won't update nicely.

It's a fairly well known problem that's been around for years, and it's the big reason why most games don't incorporate things that are dynamic based upon mouse position.

BYOND clients are limited to 1 input per tick; This includes everything from key presses/key holds to mouse clicks. Unfortunately, this also includes MouseEntered() and MouseExited().

When the system encounters multiple inputs within a single game tick (set by world.tick_lag), it will queue up the inputs.

On top of that, the traditional key macro (with the repeat setting turned on) will set off the associated input every tick.

So if you're using key macros that use "repeat", other inputs will have problems with registering. When you have a game that involves constant mouse movements, you're going to end up with the mouse and the repeating key macro fighting for the single input available per tick.

The simplest way around this is to either forgo the entire BYOND input system (which is what Hiro did with Javascript in his library), or to lower the tick_lag so that the game ticks are faster (and thus more inputs processed in the same timeframe).

This is why the whole "macro move" idea with keeping track of key up and key down gives better performance; Key Ups and Key Downs, overall, call less inputs than Key Repeat.
However, this also means that if you button mash with Key Ups and Key Downs, the performance will be significantly worse than Key Repeat.
Aug 27 2011, 2:28 pm
D4RK3 54B3R wrote:
It's a fairly well known problem that's been around for years, and it's the big reason why most games don't incorporate things that are dynamic based upon mouse position.

And it was fixed in v476. I ran this library in v476 and the movement was smooth, but slower, while keys were being held down (consistent with the idea that the ticks alternate between processing mouse and keyboard events, as opposed to keyboard events dominating). The results in v489 are completely different and keyboard events dominate again (I didn't test it, but it probably looks like it would in v475).

The simplest way around this is to either forgo the entire BYOND input system (which is what Hiro did with Javascript in his library), or to lower the tick_lag so that the game ticks are faster (and thus more inputs processed in the same timeframe).

More and more people have been running into problems with using JavaScript in BYOND, so the JS route isn't necessarily better. When it doesn't work, it typically doesn't work at all. This method would still be preferred - delayed updates are better than no updates. The forum post this stemmed from is a thread by Bravo1 looking for a way to not use HDK's library because of these issues.

The problem with upping the framerate is that, as you said, repeating keys generate events every tick. The mouse events are still fighting the keyboard events to be processed and the keyboard events still win most of the time. When you think about what this is doing to network traffic, it's not a good idea unless you were planning on using an increased framerate to begin with.
Aug 27 2011, 3:06 pm
Indeed. I have tried Hiro's mouse library in my own projects with somewhat dissatisfactory performance, but I have only ever tried it in one of my games, so I assumed that the performance problems were with my game (I saw it work relatively well in a much much simpler application).

However, I would prefer the javascript solution over the native MouseEntered(). It's not a big deal though, as both don't give ideal performance.

This problem, compounded with numerous others, are why I am disillusioned in BYOND as a development platform.
Aug 27 2011, 3:25 pm
The mouse event handling really does confuse me. It sounds like they're hesitant to add built-in support for mouse handling that would make these libraries unnecessary because they're concerned about performance, but then the library has issues because when you hold a key, the client bombards the server with keyboard input events. What's the difference? Is bombarding the server with mouse position updates really worse than bombarding the server with key repeat events?

If you output world.time when keyboard and mouse events occur, assuming that identical times means the events are processed in the same tick, it's possible to get two keyboard events in the same tick or a keyboard and mouse event in the same tick. It doesn't seem like there should be an issue with input events getting queued up.

This problem, compounded with numerous others, are why I am disillusioned in BYOND as a development platform.

I understand that BYOND wasn't made for action games, but it seems odd that the staff is so slow to add features that would help action games. It's also disconcerting that they don't know what features would be useful.

I remember reading an article that talked about how creating new laws will prevent crimes that you can't imagine. You see a crime happen and think "if only we had a law to prevent ____, this never would have happened". Yet, if before the crime happened, someone proposed that same law, it'd be hard to see the merit in it. This is similar to BYOND features - you don't know what games a new feature will lead to. But, by not adding features (or by adding them slowly) there are some good BYOND games that never got made (and ones that never even got started).
Aug 31 2011, 8:42 pm
When I was researching alternative ways to grab mosue coordinates, this was one of my first ideas, but I dropped it in favor of my current method because of all of the obviouse drawbacks; lack of any other mouse functionality and overtaxing of the dra.wing engine. I had no idea that there would be such widespread diversity in the level of JavaScript functionality. I'll be giving an overhaul to my library to address an issue and add new functionality, but is it worth it at this point?

It seems that Tom and LummoxJR need to get over themselves and include both the mouse functionality (especially considering the coming Flash client and pixel-based movement) and an included browser engine. Relying on the client's configuration without being able to know it is backwards and annoying.

P.S. I enjoyed the library. A very clever solution, indeed.
Page: 1 2