We try and fix issues whenever we run across them, or someone mentions them to us, but somethings ust aren't 3-minute corrections. Those larger issues are things which the dev team has to try and work on in their spare time -- after taking time out for work, family, food, sleep, ect... A lot of times, things end up getting put off for several weeks until somebody gets a few days off in a row and has breathing time to sit down and dig into stuff...
...and as unbelievable as it sounds, we're still *mostly* human. (All except Steve. Steve is DIVINE, after all!) The dev team tends to forget things in the busy hassle of life, and issues that we'd planned on working on, just kind of slide off to the side until somebody somewhere mentions them once again.
By placing issues in the github repository, we have a list of things to fall back on, so we don't forget an issue. It *still* doesn't mean that we'll get around to fixing it within any given timeframe, as each issue is different and some are a lot more complex than others (I'm part of the dev team, and I'm still waiting on various keyboard input issues to be fixed, and those have been around since version 1.0 and the transition from SDL to GL on us...), so folks just have to be patient with their expectations. We fix what we can, when we can, but somethings are just deeply layered core-issues.
The issue with _MouseMovementX and _MouseMovementY is that glut (our core input handling library) doesn't track relative movement. glut's solution is to: Hide the mouse pointer, track movement from last position to new position, and then recenter the mouse into the center of the screen so that it never reaches the edges...
...and that works!
At least, as long as you don't care about getting the absolute pointer position!
As we try to do both, that type of solution doesn't work for our needs. (We need both _MouseX and _MouseMovementX for folks, not just one OR the other.) For Windows, we have a simple windows API which gives that relative movement to us, so we don't have to rely on glut. For Linux and Mac... we still haven't came up with a simple plug-in solution.
Work has been done to move us towards removing GLUT out from our core dependenices (as it's awfully glitchy in many ways), so we can replace it with GLFW or something similar, but since this is just something that folks are working on in their spare time, it'll probably take a while before we reach that end goal.
So a fix like this one, I'd honestly expect to go more into the "long term correction plan", rather than anything which you'll see released in the next few updates -- and that's why something like this is so important to add to the repo issue list! After all, if we can't fix it today or tomorrow, we're human... We'll probably forget about it by the day after that, unless someone has posted us a note somewhere to remind us!
And the forums just aren't a good place for reminders. Topics get shuffled down over time, and then buried on back pages... The repo keeps open issues front and center for us, so we don't forget to delve into them when we can.
And thus, anytime someone has a real issue that they want us to look into, the best scenario is: 1) Post it on the forums first. If it's a really simple thing, one of the devs might just pop into the codebase and do that 3-minute change to fix the issue for you. 2) If the forums doesn't get it fixed, then post it on the github and be patient. Just because it's not fixed in the next release doesn't mean we're not trying to get around to fixing it. It probably just means that the issue is a little more complicated under the hood than what most folks are thinking.
![[Image: Screenshot-2024-02-24-at-11-03-45-PM.png]](https://i.ibb.co/0Ks4zcD/Screenshot-2024-02-24-at-11-03-45-PM.png)
![[Image: Screenshot-2024-02-24-at-11-03-58-PM.png]](https://i.ibb.co/9cdVfg9/Screenshot-2024-02-24-at-11-03-58-PM.png)
