Global Mouse State about fna HOT 19 CLOSED

This has to do with the fact that we track window mouse state instead of global mouse state. We actually have a call for this...

https://wiki.libsdl.org/SDL_GetGlobalMouseState

But irritatingly we have to base the XNA position on the current Mouse.WindowHandle, and while we do have SDL_GetWindowPosition, we also need information about the window borders, which is info that's only in upstream right now (and only for X11, looking into this today).

Once we have all the calls we need this can be fixed, but it'll highlight the fact that you should really only call this function once per frame...

from fna.

Upon closer examination it appears this only applies to Linux... the existing window code for Cocoa/Win32 happens to do the border thing correctly.

CC'ing @cra0zy as I believe he went in and dealt with this by changing the GetWindowPosition results. If it turns out this is the case I'll get this into fnalibs and send it off to Ryan/Sam directly.

from fna.

Just gonna add the link here as well: https://bugzilla.libsdl.org/show_bug.cgi?id=3085

from fna.

This is fixed in upstream using the latest fnalibs.tar.bz2:

86b0bc8

@cra0zy, @mrhelmut, whenever you have patches to SDL for MG, CC me in the Bugzilla report. If I can validate it before Ryan/Sam can get to it I'll be pushing it here from now on for both of us to use:

https://github.com/FNA-XNA/SDL-mirror

from fna.

@flibitijibibo Are you marking the SDL in fnalibs.tar.bz2 with SDL 2.0.5 or keeping the version at 2.0.4?

from fna.

I've kept it at 2.0.4. For MG you'll want to bump it up by hand to keep it working with the current revision's workaround check. If you want to do a workaround check without doing version checks, call SDL_SetWindowResizable; if it throws EntryPointNotFound, they're not on this branch.

from fna.

If you want to do a workaround check without doing version checks, call SDL_SetWindowResizable; if it throws EntryPointNotFound, they're not on this branch.

You and I have the same hacky workaraounds :D
https://github.com/SirCmpwn/TrueCraft/pull/245/files

from fna.

Dohoho, yeah I wish I could just check with a LoadObject/GetProcAddress, but here we are. Luckily I only ever see this get called once per game, so it's not terrible...?

from fna.

so it's not terrible...?

I think @SirCmpwn would disagree with us :P

from fna.

@SirCmpwn would disagree with us because he's totally right. But doing a LoadObject/GetProcAddress on SDL2 itself would be... interesting, to say the least. It's a very specific case.

Xwt really should do a check, but that's life with GUI libs other than ImGui.

from fna.

https://github.com/AvaloniaUI/Avalonia

from fna.

shudders

from fna.

FWIW the feature this issue talks about is meaningless on Wayland (by design).

from fna.

the feature this issue talks about is meaningless on Wayland (by design).

Why?

from fna.

Because Wayland clients don't have access to the mouse outside of their window at all. In fact, that could be meaningless in general if the compositor uses a novel design, perhaps arranging windows in 3D space.

from fna.

Additionally, a lot of mouse input stuff isn't in Wayland for reasons that mostly apply to other software - nothing other than a first-person game should ever warp the mouse, for example. Some of the bigger Linux vendors have been trying to push for compatibility, but I can totally see why it wasn't in the original spec.

My guess is that when someone writes the WL_GetGlobalMouseState in SDL it's going to just clip at the edges like GetPosition does (since it'll just get coords from event data).

from fna.

Generally speaking I don't see this feature as useful anyway within the expected use-cases of FNA/MonoGame/XNA - making games. I can't think of any game that actually needs to know about the mouse's position outside of the game window.

from fna.

The use case I've seen is cursor drawing; some just draw the cursor all the time even if the mouse is out of the viewport. For windowed mode it lets the cursor move in and out seamlessly without the cursor just getting stuck in a corner (though some fade the cursor out after it stops "moving").

There's hardware cursors, of course, but that requires some direct interop to happen (in our case it's SDL_CreateColorCursor and SDL_SetCursor).

from fna.

I guess. Seems more like a somewhat-nice-to-have than a necessary feature.

from fna.