Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardware mouse cursor #7006

Open
Hezkore opened this issue Jan 2, 2019 · 22 comments
Open

Hardware mouse cursor #7006

Hezkore opened this issue Jan 2, 2019 · 22 comments
Labels
bug

Comments

@Hezkore
Copy link

@Hezkore Hezkore commented Jan 2, 2019

I know the flickering mouse cursor issue while moving has been talked about for years, and it's still an issue while playing on a higher end computer.
Playing on a lower end computer and the mouse cursor feels extremely sluggish when the frame rate jumps up and down.

All of these issues are all related to OpenTTD rendering the mouse cursor itself (software mouse), instead of using the native OS mouse cursor (hardware mouse).
Any inconsistency in frame rate or hitches by the game is felt in the mouse movement and is also visually disorienting.

I suggest a simple solution:

  1. Add a new "Use hardware cursor" option to the "Game Options" menu.
  2. If "Use hardware cursor" is enabled; do NOT call SDL_ShowCursor(0) and never render the in-game cursor.

The standard OS' mouse cursor will be rendered on top of the OpenTTD window and behave exactly like the user is accustomed to, without any flickering or hitches to speak of.

I realize that some OS' version of OpenTTD might use its own way of moving the mouse.
But I believe the Windows version of OpenTTD simply tracks the native Windows mouse cursor position.
Which means this solution will at least work on Windows. (and probably Linux and Mac as well)

@LordAro

This comment has been minimized.

Copy link
Member

@LordAro LordAro commented Jan 2, 2019

There's been some work in decoupling the cursor (and window) rendering from the main game loop - #6780 . Can you try that out and see if it solves your issue?

@Hezkore

This comment has been minimized.

Copy link
Author

@Hezkore Hezkore commented Jan 2, 2019

Sadly I'm in no position to compile OpenTTD myself, so I'm afraid I can't test this.
Though even with a cursor and interface using its own loop; the game will still suffer from some problems with the software mouse.

For example the mouse cursor scales with the interface.
So when using a double sized interface; the cursor will look atrocious.
Which happens to be one of the problems I have with it.
Example:
Image

@nielsmh

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Jan 5, 2019

I'm not sure if Windows supports cursors larger than 32x32 pixels or some other limit. The limit might be too small to support the large animated cursors used.

@Hezkore

This comment has been minimized.

Copy link
Author

@Hezkore Hezkore commented Jan 5, 2019

Are any of the cursors actually needed though?

Alternatively you can render the software mouse when it's a non-standard cursor.
So the majority of the time the hardware mouse cursor is used, but for demolishing and placing things the software cursor kicks back in.

@andythenorth andythenorth added the bug label Jan 7, 2019
@Nik-mmzd

This comment has been minimized.

Copy link

@Nik-mmzd Nik-mmzd commented Jan 10, 2019

I tried to compile OpenTTD with disabled hardware cursor disabling (commented this line) and default SDL cursor (i think it's default SDL cursor, never worked with SDL) really "faster" that software one
+1 for "Use hardware mouse" option

@PeterN

This comment has been minimized.

Copy link
Member

@PeterN PeterN commented Jan 10, 2019

The custom cursors often indicate what action will happen when you click. By using the default hardware cursor, this information will be lost.

Some platforms allow setting a custom hardware cursor, which would be ideal.

@Hezkore

This comment has been minimized.

Copy link
Author

@Hezkore Hezkore commented Jan 10, 2019

As I said before.
The hardware cursor could always be displayed while any additional pointer information could be drawn in-game.
For example; when demolishing things you could draw the bomb at the cursor while keeping the hardware cursor visible.

Here's how that would look VS. how it looks in-game for me right now:
Image

The pointer itself does not need to be software rendered, it only causes issues.

@Nik-mmzd

This comment has been minimized.

Copy link

@Nik-mmzd Nik-mmzd commented Jan 10, 2019

...but "software" bomb near hardware cursor will move slower that cursor and it'll be... >_<

@Hezkore

This comment has been minimized.

Copy link
Author

@Hezkore Hezkore commented Jan 10, 2019

Yeah, ideally you'd want to actually change the cursor itself, of course.
But that doesn't seem to be an option (due to size and animation?) so the next best thing is to at least have the cursor hardware. If the UI eventually runs using its own ticks, then things would get better.
Though it'll never be "hardware"-good.
And software information under the cursor is not as disorienting as a software cursor.

But yeah, either you run with everything in software and have a flickering, slow mouse cursor that acts differently depending on FPS, or you convert what you can to hardware and at least fix some issues.

And to be fair!
I've seen multiple triple-A games use the hardware-cursor-with-software-info approach.
In the end, I personally feel like it's a much better solution than pure software.

@PeterN

This comment has been minimized.

Copy link
Member

@PeterN PeterN commented Jan 10, 2019

I'm not saying it's a bad idea, by the way, just something to take into consideration.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Mar 11, 2019

This issue has been automatically marked as stale because it has not had any activity in the last two months.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale label Mar 11, 2019
@nielsmh nielsmh removed the stale label Mar 11, 2019
@nielsmh

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Mar 11, 2019

This is still relevant IMHO.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented May 10, 2019

This issue has been automatically marked as stale because it has not had any activity in the last two months.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale label May 10, 2019
@stale stale bot closed this May 17, 2019
@Hezkore

This comment has been minimized.

Copy link
Author

@Hezkore Hezkore commented May 17, 2019

So long hopes and dreams!

@Nik-mmzd

This comment has been minimized.

Copy link

@Nik-mmzd Nik-mmzd commented May 17, 2019

Meh.

@LordAro LordAro removed the stale label Jan 10, 2020
@LordAro

This comment has been minimized.

Copy link
Member

@LordAro LordAro commented Jan 10, 2020

Stupid stalebot

@LordAro LordAro reopened this Jan 10, 2020
@OpenTTD OpenTTD deleted a comment from liquid245 Jan 10, 2020
@Nik-mmzd

This comment has been minimized.

Copy link

@Nik-mmzd Nik-mmzd commented Jan 10, 2020

@LordAro maybe you'll add "pinned" label to make Stale bot not mark this issue as stale?

@LordAro

This comment has been minimized.

Copy link
Member

@LordAro LordAro commented Jan 10, 2020

In theory yes, but we turned stalebot off a few months ago :)

@Nik-mmzd

This comment has been minimized.

Copy link

@Nik-mmzd Nik-mmzd commented Jan 10, 2020

Ohh, missed that

@nielsmh

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Jan 10, 2020

I experimented with hardware/system cursor on Windows a little while ago, branch here: https://github.com/nielsmh/OpenTTD/tree/win32-syscursor

Two important points:

  • Windows supports at most 48x48 pixel cursors, and some OTTD cursors are larger than that.
  • Converting the cursors from sprites to Win32 cursors is not quite straightforward.

In my opinion this is not worth chasing further for Win32.

@Hezkore

This comment has been minimized.

Copy link
Author

@Hezkore Hezkore commented Jan 11, 2020

I experimented with hardware/system cursor on Windows a little while ago, branch here: https://github.com/nielsmh/OpenTTD/tree/win32-syscursor

Two important points:

* Windows supports at most 48x48 pixel cursors, and some OTTD cursors are larger than that.

* Converting the cursors from sprites to Win32 cursors is not quite straightforward.

In my opinion this is not worth chasing further for Win32.

100% hardware cursor might be out of the question, but see #7006 (comment) for a cross-platform way of handling mouse cursor information.

@KerekesDavid

This comment has been minimized.

Copy link

@KerekesDavid KerekesDavid commented Feb 13, 2020

In my opinion either Hezkores solution, or at least a simple toggle off would be really welcome. I would gladly lose the bomb icon feedback to have a mouse pointer that feels responsive.

The current one on windows feels really jarring, especially if played in a window, switching between the software and hardware cursors is awful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.