Godotsteam: Steam overlay problem in MacOS binary?

[cfcohen]

I have not investigated this carefully yet, because I wanted to see first whether anyone else was able to reproduce it, whether it was a known problem, etc. The problem is:

In a game using GodotSteam, compiled for the Mac platform (but NOT Windows or Linux), activate the Steam overlay (shift+TAB). Instead of sending mouse events to the overlay, it appears that the mouse events are still being sent to the underlying game which is not sufficiently "paused".

In particular, certain hover events are happening in game under the overlay, while operations that should work in the overlay like clicking on links, moving windows, etc. does not work as intended because the overlay doesn't seem to be receiving them.

This all smells to me like something that's likely to be missing the handoff to the Steam overlay. Is there any reason to believe that this could or should be different for MacOS than the other platforms? Any insights you have would be appreciated.

[SapphireMH]

@cfcohen Are you saying this only happens in the MacOS version? In windows or Linux the problem does not occur?

Which version of MacOS and Godot are you using?

[cfcohen]

Yes, for the same project build, I'm experiencing the problem only in the MacOS executable. Mac OS BigSur 11.0.1 and the latest "release" binary template in the GodotSteam repo. I've just recently built my own Godot+GodotSteam off the tip of Godot 3.2 and master on GodotSteam. I haven't finished testing that configuration though.

So I just confirmed (to the best of my ability) that the problem persists when Godot and GodotSteam are built from current sources, so the problem is not related to a build problem that's specific to the latest template release. This suggests to me that problem is somewhere in GodotSteam or my Godot project, although frankly I have a hard time imagining what I might do that would work on Windows and Linux, but fail on MacOS, specifically related to the Steam overlay. I have also confirmed that other non-Godot games having working overlays on the same Mac. Obviously, there's some difficultly in testing a different Godot game with the Steam overlay on the Mac (like I don't know that I own another Godot/Steam game).

[Gramps]

@cfcohen I briefly tested it in Windows 10 and there does not seem to be any issues with it moving things under overlay in the game. I also tested it out on Linux (Ubuntu 16.04 and Ubuntu 20.04) and it works fine as well. It is most likely a MacOS specific issue.

That being said, I have seen non-Godot games where this behavior occurs both on Windows and Linux. I'm not sure if OSX handles OpenGL differently for some reason or not.

[Gramps]

@cfcohen Try downloading Virtual Cottage on Steam. It's free, has a OSX version, and the devs are really nice folks. It is using GodotSteam as well; I believed the pre-compiled version.

[cfcohen]

I've tested Linux personally and found it work fine as well. I have a first-hand report from a trusted beta-tester that the Windows version works too. So your results match mine so far. I've personally observed the problem in MacOS on two different Macs, (sadly both running the latest BigSur, so I can't offer much variety there). It does appear to be a MacOS specific problem, and could easily be something like how it's handling OpenGL. I've tried to establish where the problem is related to my game opening in a "window" but I see the same behavior after switching to "full screen" from the Mac menu.

Will do. Do you have a Mac to test with?

[Gramps]

Hmm, yes, this is probably an OpenGL issue which means there isn't much I can do about it. There is a way to "work around" the issue by checking when overlay is opened and pausing your game's input, but that seems pretty hack-y.

[cfcohen]

Darn. So it works in Virtual Cottage. I noticed that the Steam overlay is in a substantially different resolution though. Maybe that's a clue. I've been mastering my content in 3840x2160, and I'm having some other "HiDPI" issues. Maybe that's related. This at least gives me something to continue to investigate. I'll get back with more research later this evening.

[Gramps]

Interesting. Yeah, the devs of Virtual Cottage are using the pre-compiled builds which, I believe, you said you tested on. So maybe, as you say, it's something related to HiDPI. That being said, I wonder what video settings in Godot would break this kind of behavior and why... and if this is something that should be addressed by the Godot Engine devs.

[SapphireMH]

@cfcohen I have a Mac, also running Big Sur, I'll check a few games tomorrow to see if I can reproduce the issue.

[cfcohen]

So I spoke too soon. I can reproduce the problem in Virtual Cottage, in just manifests a little bit differently than I had previously perceived in my game. The problem is better characterized as mouse events going to both the game and the overlay, with some difficult to identify mouse offset problem that looks like it might be related to the offset of the window relative to the top left corner of the screen or something like that.

For example, you can click the mouse at places that have no steam overlay GUI elements, and instead it activates some nearby GUI element. I had previously thought that no mouse events were going to the overlay at all, but that's not true. You just need to learn what the offset is and react appropriately. When I was testing my game the HiDPI was an aggravating factor because the GUI elements were all so small that it was very difficult to activate a control without seeing where your mouse was really at. The most obvious sign that this is happening is that mouse pointer changes styles based on where the pointer is supposed to be, not where it's being drawn (e.g. changing from grab hand, to a text cursor, to an arrow).

I also observed a very strange behavior (just once) where dragging the game window caused the "Friends" overlay window to move relative to the game screen background. This last behavior in particular now makes me wonder if the problem isn't actually in the steam overlay itself, and is related to "windowed" games versus full-screen games.

[cfcohen]

Excellent (at least for me). So I've now confirmed two more important things. It works just the same in my game as it does in Virtual Cottage, and the problem does indeed seem to be related to windowed versus full-screen mode. To get fully working behavior, start the game, click the green fullscreen widget at the top of the window, and then activate the overlay. Mouse offset works as expected. When the overlay is started in windowed mode it does not. The same invocation of the game, will demonstrate both the working and broken behaviors.

The correlation between the buggy mouse behavior and the position of the window relative to the screen was best demonstrated to me by watching what mouse position activates the "Click here to return to the game" link. That link is always highlighted when the mouse is very near the top of the screen (rather than the top of the window).

I think it's pretty clear at this point that someone is incorrectly using the "screen coordinates" for the mouse when they're supposed to be using the "window coordinates". I'm inclined to blame Valve at this point since it only affects the overlay, but I suppose it could be a Godot problem as well. For now I'm going to mark this one down as "not my fault" and move on. Does anyone have enough experience to know where and how to report this to Valve (I do not. I'm only about 30 days into this whole experience).

[Gramps]

Now that's what I call investigation!

The mouse thing being off is something I've had happen in Godot games when I mess with the display settings, as have some beta testers of mine in the past. It's actually hard to say if this is an issue with Godot or Steamworks' overlay. A good indicator would be if there are similar issues, minus the Steam overlay, with other uses of Godot. Like I said, I've had similarly odd mouse behavior with certain screen settings in 2D. Keeping aspect ratio, etc.

As far as asking Valve about it, the best way is to use either the developer group or send them an e-mail through the Steamworks website. Honestly the developer group barely gets any responses from staff; mostly just moderators who aren't actual Valve employees. I would really lean to sending them an e-mail in the Steamworks website.

[SapphireMH]

@cfcohen I've been able to reproduce the issue you have been seeing, but the issue also occured in Celeste, which is not a Godot game, I am fairly certain the issue lies with Valve / Steam, so there is nothing we, or the Godot dev team can do about this sadly.

As for how to report this to Valve, I am not certain, maybe @Gramps can give you some insight into that proces.

If you don't have any further questions or things we can assist you with, the issue can be closed.

We also have a discord server where GodotSteam can be discussed with us and other devs that use it here:

https://discord.gg/RtGgxSM

[Gramps]

@SapphireMH I'm not sure I totally agree. It could be Godot and Celeste handle OpenGL in the same way. If this happened to all MacOS games, then it would definitely be a Steamworks issue. I see weird behaviors with overlay and different games on both Windows and Linux which often falls back to the engines used and their display systems.

Either way, as you mentioned, there is nothing we can do about it. It definitely falls back on Valve and the Godot Engine devs.