About Trove mouse broadcasting issues
So I've done some a bit of digging to figure out what's going on with mouse broadcasting in Trove, and why it's less consistent than it should be. It turns out that Trove's mouselook is somewhat broken, in part due to using an outdated SDL2 API, and also in part due to using the API "wrong".
There's two ways of handling the mouse cursor -- absolute and relative modes. In absolute mode, you usually see the cursor and it is limited in where you cam move it; there is an edge to the window, the screen, etc. In relative mode, you usually don't see the cursor and you want to move it without limits ... spin around many times by moving the mouse continuously in the same direction. You also expect it to be consistent as you move the mouse.
Trove's first mistake is that mouselook is done using SDL's absolute mode instead of relative mode, just with a hidden cursor. That would be okay, but Trove's second mistake is not re-centering the mouse after each movement, meaning it is much easier to hit the edge of the window. That wouldn't be so bad, but the version of SDL Trove is using locks the cursor positioning inside the window (so if you move the hidden mouse cursor toward the window edge, then jerk it past the window edge, you barely turn) AND stops notifying Trove of mouse movements once it hits the edge. So you get this kind of start-stop thing instead of a smooth motion, entirely due to Trove's method of using this outdated SDL.
With that said, I have managed some improvements. I'm still digging through SDL to see if there's a way to further correct the behavior, assuming Trove developers don't want to hear about this. (If they do, they could at minimum update SDL, and at best switch to relative mouse mode)
The best advice at the moment is still to get your FPS in all windows to the same value, e.g. 30 foreground and 30 background FPS during the CPU Strategy Wizard, and for the game resolution to be the same in all windows.
There's two ways of handling the mouse cursor -- absolute and relative modes. In absolute mode, you usually see the cursor and it is limited in where you cam move it; there is an edge to the window, the screen, etc. In relative mode, you usually don't see the cursor and you want to move it without limits ... spin around many times by moving the mouse continuously in the same direction. You also expect it to be consistent as you move the mouse.
Trove's first mistake is that mouselook is done using SDL's absolute mode instead of relative mode, just with a hidden cursor. That would be okay, but Trove's second mistake is not re-centering the mouse after each movement, meaning it is much easier to hit the edge of the window. That wouldn't be so bad, but the version of SDL Trove is using locks the cursor positioning inside the window (so if you move the hidden mouse cursor toward the window edge, then jerk it past the window edge, you barely turn) AND stops notifying Trove of mouse movements once it hits the edge. So you get this kind of start-stop thing instead of a smooth motion, entirely due to Trove's method of using this outdated SDL.
With that said, I have managed some improvements. I'm still digging through SDL to see if there's a way to further correct the behavior, assuming Trove developers don't want to hear about this. (If they do, they could at minimum update SDL, and at best switch to relative mouse mode)
The best advice at the moment is still to get your FPS in all windows to the same value, e.g. 30 foreground and 30 background FPS during the CPU Strategy Wizard, and for the game resolution to be the same in all windows.