Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / SetRawMouseVisible()

Author
Message
Nieb
9
Years of Service
User Offline
Joined: 13th May 2014
Location: Lurking
Posted: 2nd Jul 2022 00:21 Edited at: 2nd Jul 2022 04:00
Years ago I found SetRawMouseVisible() to be unreliable. So, I thought I'd try to figure out what was going on:
At first, I thought it was just the WinAPI being janky. However, after a bit of testing, it appears it's not an ON/OFF flag, but instead it buffers every time the command is sent. If you do SetRawMouseVisible(1) 5 times, then you must do SetRawMouseVisible(0) 6 times to have it actually set visibility OFF.
I don't know if this is a bug or intended behavior, but I at least find it undesirable behavior.

A quick test program to demonstrate the behavior:


Here's a hack to work around the issue:
Virtual Nomad
Moderator
18
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 2nd Jul 2022 02:03 Edited at: 2nd Jul 2022 02:40
i'm no guru, but:
microsoft wrote: "
Remarks
The Show and Hide method calls must be balanced. For every call to the Hide method there must be a corresponding call to the Show method."

which, according to your findings above, is true?

otherwise, another way to skin your cat?

admittedly, i'm not quite sure which cat needs fleecing
Nieb
9
Years of Service
User Offline
Joined: 13th May 2014
Location: Lurking
Posted: 2nd Jul 2022 03:57
Ah, so it is WinAPI jank.

Perhaps we could update AppGameKit to intervene and handle this in a not-stupid way. Like our work-around functions.
adambiser
AGK Developer
8
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
Posted: 3rd Jul 2022 04:53
It's not stupid depending on what you're doing.

The fact that it stores an internal count eliminates the need of remembering cursor states everywhere in external code.

This opens up the possibility for external code somewhere not doing this and instead doing what you want it to do introducing a bug where the cursor becomes visible too early that could be difficult to track down. The API keeping track itself takes care of this.

In a game scenario, though, what you're saying is probably what most people would expect.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 4th Jul 2022 00:10
You could turn it off entirely an make you own cursor using a sprite.
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 4th Jul 2022 13:42
Microsoft are usually in a difficult position when it comes to updating their APIs.
What might seem like strange or clumsy approaches today., made more sense when they were first implemented.

Something to keep in mind is that during the Early 90s with the advent of the Graphics Card, came the 2D Accelerator.
These weren't just Display Adapters., but Graphics Chips that would accelerate various Graphics Tasks... one such task was a Hardware Mouse Cursor., as well Graphics User Interface Operating Systems (Windows) were becoming more common.
A Software Mouse Cursor was quite a performance heavy task... so, offloading it to Hardware helped quite substantially with System Performance.

This however poses a problem... as Hardware doesn't work like Software., they don't "Store" per se; they merely act upon the last state you set and you can't really get any feedback.
As such, there is no way to know if the Hardware Mouse Cursor is Hidden or Visible.
What we also have to consider is that flooding the Window Message Queue with a Hide/Show Command every Synchronisation Loop., well that would add CPU Overhead.

As a result., this message is sent once and is passed on to the Graphics Card; which then behaves based on the last state sent to it.
If we want to change that; then we'd have to see a different command to it.

Now Graphics Cards had (dedicated) 2D Acceleration Components until 2009., the introduction of the AMD Compute and NVIDIA Unified Shader Architectures.
As a result the Cursor switched back from Hardware to Software., although it's still Hardware Accelerated as now it's a Shader Sprite; but here's the thing of it... Microsoft can't simply change how this works.
Why? Well because there is at least a Decade of Software that still remained 100% Compatible with Modern Windows; that still uses these commands how they used to work.

So they can't just change how this works. Even IF there is arguably a much better way, not without breaking all those old applications.
...

I mean *we* as Developers can easily switch this into being a Flag.

MouseCursor.agc


Main.agc


It works every time

Login to post a reply

Server time is: 2024-03-29 11:23:24
Your offset time is: 2024-03-29 11:23:24