Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A _MOUSEMOVEMENTX question
#21
(02-13-2024, 11:36 PM)NakedApe Wrote:
(02-13-2024, 10:44 PM)SMcNeill Wrote: You may want to look here: https://qb64phoenix.com/forum/showthread.php?tid=2102

Thanks, Steve. I have read that helpful post of yours already. The issue here is that _MOUSEMOVEMENTX doesn't work right in macOS - and Linux apparently. You can't scroll endlessly on my computer and get results... alas. Maybe our resident Mac expert, @a740g, could have a look when he gets a chance. Thanks.

I am no mac expert, but I'll check nonetheless. Smile

@grymmjack told me that it works on his mac though.
Reply
#22
(02-14-2024, 12:39 PM)SpriggsySpriggs Wrote: Mac has some licensing thing that they only want Mac OS to be ran on Mac hardware. I think VirtualBox is the only VM software that is able to run Mac. I managed to make it work many moons ago but I had an Intel processor and it was incapable of running the Mac environment at any usable speed.
I have a VirtualBox image with MacOS11 that I use to test and compile for Mac.
I can share if someone wants it (45GB)
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Reply
#23
@NakedApe

It seems to work fine for me on macOS (Ventura 13.6.4) I think. What am I missing?


[Image: Screenshot-2024-02-24-at-11-03-45-PM.png]


[Image: Screenshot-2024-02-24-at-11-03-58-PM.png]


Update: I checked with @SMcNeill and @DSMan195276 and see the issue clearly now. Like @DSMan195276 said earlier in this thread, _MOUSEMOVEMENTX/Y are not properly implemented on macOS and Linux. This issue should go into the GitHub issue tracker.
Reply
#24
Thanks, a740g, for looking into this! And I'm glad you see what I see - and that I'm not crazy...  Wink

So does putting this into the GitHub issue tracker mean one of you fine developers will tackle the problem someday? No pressure from me, just curious about resolution... Thanks again.
Reply
#25
(02-24-2024, 08:04 PM)NakedApe Wrote: So does putting this into the GitHub issue tracker mean one of you fine developers will tackle the problem someday? No pressure from me, just curious about resolution... Thanks again.
Yep, that's exactly what it means. Please feel free to open one here: https://github.com/QB64-Phoenix-Edition/QB64pe/issues. Here, you can see the open/closed issues. We do look at this list, fix, and close whatever we can with the limited time we have. So, no promises on ETA.  Big Grin
Reply
#26
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.  Wink
Reply
#27
Thanks vm, a740g and Steve. I set up a GitHub account (tho username NakedApe was taken?!!?) and posted the issue there. I appreciate the explanations and developer POVs. Keep up the good work! Smile
Reply
#28
@NakedApe @bplus You guys might want to take a look at this little code snippet here: https://qb64phoenix.com/forum/showthread.php?tid=2465
Reply
#29
OK passed this on...
b = b + ...
Reply




Users browsing this thread: 1 Guest(s)