SFML community forums
Help => Window => Topic started by: ilovemac on September 17, 2023, 09:47:15 pm
-
Hi there! ;)
I have a problem, with setting the Mouse cursor position via
the Mouse.SetPosition function.
The function works under Windows, but not with Linux.
I've narrowed it down to some kind of error with setting the Mouse Position.
That means, all my events, etc. work just fine.
One thing I have observed, the Mouse Cursor actually moves to the given coordinate,
but then instantly gets moved back to it's original location.
( I've tested this, by moving the cursor to a coordinate, with a Button over it.
The Button briefly got the Selection color and the Cursor Icon changed. )
I don't know if this is the right forum to ask this.
If it's a problem with SFML Cursor in general under Linux or a problem on the Linux side.
I use C# DotNet 6, SFML 2.5.1 under Arch Linux (Plasma KDE, newest kernel)
Thanks in advance ;)
-
Does it also not work if you first grab the mouse frist?
https://www.sfml-dev.org/documentation/2.6.0/classsf_1_1WindowBase.php#a0023344922a1e854175c8ca22b072020
-
No, unfortunately it doesn't solve the issue.
But, moving the Cursor inside of the Window bounds
( i.e. Mouse.SetPosition(new Vector2f(10, 10), this); )
Results in my Thread "lagging"
But not, when moved outside of the Window.
Hmm, maybe it's a problem with my Events after all, but I'm not sure.
In my main Loop, I use the DispatchEvents method.
Very weird :/
-
Are you using multiple threads?
Would you be able to compile a C++ example?
-
Yes, I'm using multiple threads.
But I only use one, aside from the Thread, where my Window runs,
to reset my FPS Counter and to do some other non-related SFML stuff.
I've also made a "blank" project.
Just creating the window and the game loop:
public class Program
{ public static void Main
(string[] args
){ new Main
(); }}public class Main
: RenderWindow
{ public Main
() : base (new VideoMode
(800,
600),
"Test"){ this.SetFramerateLimit(60); this.SetVerticalSyncEnabled(false); this.MouseButtonReleased += (sender, e
) => { Mouse
.SetPosition(new Vector2i
(100,
100)); }; while (this.IsOpen){ this.DispatchEvents(); this.Clear(); // Draw Window this.Display(); } }}
Same Issue :/
-
I can't recommend using multiple threads. There are a lot of things to consider.
It's okay if you off load some CPU workload, but you should always use SFML in your main thread.
What if you don't change the mouse position inside the event handle?
-
No, nothing changes :/
(pic related)
Like said before, the Mouse Cursor "moves" to the given Location,
but appears in it's original spot.
I can also move the Mouse freely, even if the Cursor is set constantly per Code.
In the picture, you can see, that the VSCode element, where the Mouse Cursor is
moved, it beeing activated.
But if I press the Mouse button it should tecnically Invoke the VSCode element.
But it doesn't. So It's not a display issue
-
Okay, "good news" here!
I've managed to get resolve my problem!
I can now, freely set the cursor to the coordinate, I want.
All, I've done is start my Desktop session in X11 instead of Wayland,
and run my Program in there.
But, this is kinda weird.
As far, as I know, SFML hasn't updated to Wayland yet. It's still on X11.
And, X11 Applications are compatible with Wayland trough the xwayland compositor.
Maybe I should bring this to some Linux forum.
Just wanted to share, for anyone who's having a similar problem ;)
Thank you all 4 your support ;D
-
Can you try to build SFML 2.6.0 from source?
Maybe there has already been a fix for it?
For now, I've created an issue to track it: https://github.com/SFML/SFML/issues/2750
-
I can't seem to find how to build the new Version from source, for C#
I've tried cmake but that only gave C++ libraries :/
I will try out other (older) SFML Versions for C# and see
if the issue persists throughout these versions too
-
You have to build SFML and use that to build CSFML and use that for SFML.Net
But as you can see from the issue linked above, the problem hasn't been solved.
It's additionally unclear if we can ever solve this, as Wayland intentionally prevents the setting of mouse position for "security" reasons.