I'm building a custom container view that is a stack of cards piling on top of each other (each card is a child view controller.)
Now there is a motion where the user could "pick up" the card and I am currently implementing it like this:
On first touch-down-inside, I adds a UISnapBehavior. The card "snaps" during a small duration onto the user's finger.
After a small delay, UISnapBehavior is removed and UIAttachmentBehavior is put in place (so I can update the anchor point as the user moves his finger around.)
Now this presents 2 problems:
If the user moves his/her finger while UISnapBehavior is active, I'll remove the snap behavior and replace it with UIAttachmentBehavior but doing this causes a visible visual glitch where the card bounce a bit before attaching to the finger. This is in a small duration but still very visible.
If I use UIAttachmentBehavior directly, I cannot configure it to work in the same way the snap behavior works. Either there is too much spring animation or too little snapping feels.
Now what I wanted is the following:
When the user first touch the card, the card should snap onto the finger (there is a designated anchor point on the card where the finger should goes, so that point snaps to the finger when the card is touched)
When the user moves the card, the card should moves along with the finger.
When the user release the finger (touch-up) there should be a small residual acceleration going, this is already done using a UIDynamicItemBehavior.
So is there a way I can get UISnapBehavior-style attachment (to the finger) but still allows the anchor to move around?
Do I need to roll my own custom behavior for this?
Related
The issue.
The mouse keeps escaping the full-screen whenever I either jump, move, rotate the camera or keep spinning to the left. But only on the left side of the screen, not the right, not the middle, not beneath, only on the left side.
This has happened in other unreal engine 5 games as well, but not in every single one of them.
What I've tried so far is:
Disabled Set bSHowMouseCursor nodes. [No effect.]
Set an Event BeginPlay > Set Input Mode Game only > Get Player Controller > Set SHow Mouse Cursor (Unchecked) [No effect.]
Created a new template (A blank one), then packaged it for testing. [Mixed effects. It slightly reduced the rate the mouse showed on the left side of the screen.]
Set an Event BeginPlay > Set Input Mode Game and UI > Get Player Controller > Set SHow Mouse Cursor (Unchecked) [Mixed results - I had to hold right click in order to move the camera, in which case, the mouse stopped showing, but as soon as I released it, the left mouse not only did appear as well, but the camera could not be moved and the cursor appeared permanently on the left side of the screen.]
Changed both the software and hardware cursors. But the cursor is unchanged. So it's not the game's cursor that appears in-game. It's the actual windows cursor.
I tested every option in the Default Viewport Mouse Lock Mode.
Deleted both Saved and the Intermediate folders.
Someone told me it has something to do with how the mouse is locked (or not) on viewport. And that, that might be the reason behind the cursor leaving escaping full-screen.
I don't have two monitors. The game is in full-screen. The issue persists in windowed mode as well. No widgets.
Tested it in packaging and in a Standalone game. (Issue persisted.)
The issue happens only if I click the left mouse button. If I play the game without clicking it, the cursor does not appear in-game.
Update:
It appears like going to the game's exe's compatibility and changing the high DPI settings' scaling behavior to application fixes the problem but reduces the fps. This is a temporary fix but I need a permanent one.
This is a weird issue.
What is on your left side desktop?
Do you use any apps that have an overlay?
If you have any apps try to disable them temporarily at startup from task manager, restart and check again.
In UE5, have you tried setting the mousecapture to true, especially in fullscreen.
Sometimes the mouse can escape...
Are you using a standard resolution/aspect ratio?
Some non standard resolutions and aspect ratios can change the way the base OS responds to captured/non captured input.
I am chasing a bug that I suspect is my own misunderstanding about X:
TL;DR - Sometimes XEnterNotify events give global mouse coordinates that don't correspond to the window being entered.
I'm modifying a tiling window manager (ratpoison). The screen is divided into frames, each of which may contain a mapped window. If a frame contains no window, I'd like to focus the frame. So I ask for EnterNotify events on the root window, cast the XEvent to an XCrossingEvent, and then look at x_root and y_root to figure out where the mouse is on the screen. I expect to get the global screen coordinates. The problem is that sometimes when I move the mouse over the empty frame, I get an EnterNotify event on the root window, but the (x_root, y_root) members of the event give a point in the frame I came from (i.e., not at an exposed part of the root window).
Any suggestions?
I think the answer is the following:
The mouse coordinates are not guaranteed to be in sync with anything in particular. The only thing that seems really to be guaranteed is that the mouse was at one point at these coordinates and that a later event will have a later mouse position. In order to know the true mouse position, I either need to listen to motion events on the root window (so that I will eventually get the information I want) or else call (probably) XQueryPointer().
Note that I am not 100% certain of this answer.
I'm using WM_MOUSEMOVE to get changes in mouse position. When simulating "knobs" for example it's desired to let the user go up/down with mouse without any limits. In this cases I hide cursor and use SetCursorPos to change its position every time user moves with it and detect just the difference from the original position.
Unfortunately it doesn't seem to work - if I set the mouse position, it sometimes works, but sometimes is one or more pixels away, which is just wrong. And even bigger trouble is that after the call another WM_MOUSEMOVE seems to be delivered, which unfortunately does the same thing as it wants to move the cursor back to the original position again. So it ends up in an infinite cycle or settings mouse position and receiving messages until the user releases the mouse button.
What's the correct approach or what's the problem?
The raw input system can do this - it lets you register for raw mouse input that isn't clipped or confined to the screen boundaries.
Broadly speaking, you register for raw input using RegisterRawInputDevices(). Your window will then receive WM_INPUT messages, which you process using the GetRawInputData() function.
See Using Raw Input for an example.
I hide cursor and use SetCursorPos to change its position every time user moves with it and detect just the difference from the original position.
This is just plain wrong. Instead, use SetCapture() to capture the mouse. All movements will be reported as WM_MOUSEMOVE messages with coordinates that are relative to the specified window, even if the mouse is outside of that window, until you release the capture.
Asking the user to move the mouse continuously, even after the cursor hit the screen limit is a very bad idea in terms of User Interface, IMHO.
Some games have another approach: when the mouse hit the "limit", the game enter a special mode: things appears to function exactly as if the mouse was moving, even if the user don't move it. When the user wants to exit that mode, he just has to move the mouse of the limit.
Doing so requires a timer, armed when the mouse hit some limit, executing code periodically as if the mouse was moving. The timer is stopped when a real mouse movement makes it leaves the limit.
Ok folks, so I found a solution simple enough:
The main problem is that SetCursorPos may not set the coordinates accurately, I guess it's because of some high resolution processing, nevertheless it's probably a bug. Anyway if SetCursorPos doesn't set the coordinates correctly (but +-1 in x and/or y) it also sends WM_MOUSEMOVE to the target window. As a result the window performs the exact same operation as before and this goes on and on.
So the solution is to remove all WM_MOUSEMOVE messages right after SetCursorPos:
MSG msg;
while (::PeekMessage(&msg, NULL, WM_MOUSEMOVE, WM_MOUSEMOVE, PM_REMOVE)) { };
Then retrieving the current mouse cursor pos using ::GetCursorPos .
It's ugly but seems to fix the problem. It basically seems that in some position of the mouse, the system always adds or subtracts 1 in either coordinate, so this way you let system do the weird stuff and use the new coordinates without trying to persuade system that your coordinates are the correct ones :).
I want to implement an application on my website where once the users are connected, they share a text editor. If one user enters anything on
the text editor available on his screen, the same text appears on the second user’s
screen at the same coordinates.
Same thing goes for the other user. Also there would be pointer shaped images on both user’s screens to represent mouse pointers.
When user A moves his mouse pointer, the image on user B’s screen should be
moved according to the movement of user A’s mouse and similarly, when user B
moves his mouse, the image on user A’s screen should be moved accordingly.
The problem is I am using database to store the coordinates of each user. And this approach results in the a lot of lag and delay. What should I use in place of the database?? Please Help !
You probably don't want to request the updates but push them to your clients: http://en.wikipedia.org/wiki/Comet_%28programming%29 . This reduces the delay between an update from your client to the server and other clients again checking for updates.
how abt using Redis : http://code.google.com/p/redis/
an example of a similar collaborative text editor using this : http://www.web2media.net/laktek/2010/05/25/real-time-collaborative-editing-with-websockets-node-js-redis/
Whenever I write mouse handling code, the onmousedown/onmouseup/onmousemove model always seemed to force me to produce unnecessarily complex code that would still end up causing all sorts of UI bugs.
The main problem which I see even in major pieces of software these days is the "ghost mouse" event where you drag to outside the window and then let go. Once you return back into the window, the application still thinks you have the mouse down even though the button is up. This is especially annoying when you're trying to highlight something that goes to the border of the screen.
Is there a RIGHT way to write mouse code or is the entire model just flawed?
Ordinarily one captures the mouse events on mouse down so the mouse move and mouse up go through your code regardless of the caret moving out of you application window.
More recently this is a problem when running a VM or remote session, its difficult for apps in these to track the mouse outside of the machine screen area represented by a window on a host.
I'm not sure what environment you're attempting to track mouse buttons in, but the best way to handle this is to have a mouse listener that tracks onmouseup 100% of the time after you've detected onmousedown.
That way, it doesn't matter what screen region the user releases the mouse button in. It will reset no matter where it happens.