I currently try to integrate the Steamworks.Net library into a MonoGame 3.6 project and it worked fine in both DesktopGL and Windows project with a small difference:
In the Windows project the steam overlay is not showing. In the DesktopGL project the steam overlay is showing correctly.
In MonoGame 3.5 the steam overlay is showing in the Windows project as well as in the DesktopGL project.
Please take a look at this repo:
The master branch contains the DesktopGL version (which is working correclty).
The “xTest” branch contains the Windows version (which is basically working but not showing the steam overlay anymore (in MonoGame 3.5 it was working fine)).
Aren’t there some debug events to check steam commands are correctly triggered ? (to see if alt+tab is correctly seen, or if nothing prevents steam from drawing ?)
May it be caused by an update to the steam client using dx ?
You received a “NoAudioHardwareException”. It seems you don’t have a correctly installed audio hardware.
Does windows shows a red cross on your speaker icon?
Regarding my error:
It seems that the steam overlay generally can’t be hooked into the MonoGame render window (in the windows project). What I found out is, that Steam tries to hook wglSwapBuffers but should use d3d to show the overlay in the windows project.
What I don’t understand is, why it automatically worked in MonoGame 3.5 windows project and not in MonoGame 3.6 windows project. It seems that something changed since then.
I try to further investigate this behavier. Would be nice to find a solution on that.
The problem was that the steam overlay needs to get injected before D3D/OpenGL are initialized. For a reason it is possible to test the steam overlay function directly in a debugging session through visual studio, but this does not count for a windows project of MonoGame.
The solution for the windows version of a MonoGame is, to compile the project and then launch the output (.exe) through the steam client. For debugging purpose you can add the compiled exe to your steam client as a “Non Steam Game” and then launching it by clicking the play button in the steam client.
The steam overlay should be successfully injected now. This can be checked by opening your task manager and searching for the process “gameoverlayui.exe” (it’s from steam).
I created a new branch called “Windows” with the newest commits in it. At the moment I have a branch for DesktopGL projects (master) and Windows projects (Windows). I will create a better solution later.
Further I will work together with @throbax on this repo to add more interesting and meaningful features to it like “SteamAPI.RestartAppIfNecessary()” to ensure that the game will be launched through steam (soft DRM and also to ensure that the steam overlay will be correctly injected) and “SteamAPIWarningMessageHooks” for receiving warning messages from steam (debugging).
Did an update to MonoGame or Steamworks.Net break this? I’m working on a Steam release using the “MonoGame Windows Project” and can’t seem to get the Steam overlay to work… I can see the SteamAPI and dll is being found and all that seems good at least when I’m debugging. It’s almost like something with MonoGame, or maybe even something specific to my game, is blocking the overlay injection since I don’t even see the gameoverlayui.exe in the task manager when I run my game through Steam.
This happens frequently for many users. Unfortunately I didn’t updated the repo with additional information so far.
Try this:
Build your solution, add your app to your SteamLibrary and run it directly from within Steam.
This should definitely inject the steam overlay. If not, then something is blocking the injection like a virus scanner / firewall or a different overlay like a performance monitor.
It’s already running through Steam and I get SteamOverlayActive == true after doing a callback for its activation. It’s there, it just won’t render for some reason.
I just tested it with a windows build and the overlay is still showing up when I start from the steam client.
Please read the official steam overlay documention and try to pin down the problem.
Sometimes other programs running in the background avoiding the successful injection of the overlay like for example the RivaTunerStatisticsServer, which has its own overlay.
I don’t have an issue with the steam overlay not working in general. I have an issue specifically with it not working for my game that’s using MonoGame Windows build. If it was an issue of some software running in the background blocking it, then it wouldn’t work at all for any game. If yours is working without any issue, then it’s something I’m doing wrong and that’s what I actually need help with. Is there any known ways of accidentally blocking the overlay via some particular way of rendering, resizing the window, toggling fullscreen, or anything along those lines? Would save me a lot of time if anyone’s already been down this road and could list some possibilities. Otherwise I’m looking at starting with a bare-bones build and adding stuff one line at a time until I figure out what’s breaking it… would be nice to avoid that.
There is a possibility that the overlay gets injected in the “wrong” window. For example when your game has a launcher which for itself has its own render surface (which hooks in the overlay). Then it could happen that the actual game window will not receive the overlay injection.
From my experience this is rare. I even created a multi viewport application with Steamworks.Net and the last created / active render surface always got the overlay injection correctly.
But I experienced that when the back buffer has a different size than the actual render surface, then the overlay can get stretched and distorted; maybe even invisible if the true render area is to small. This is something which could happen in editor environments but I did not see that so far in games.
Did you try the “Hello Steamworks.Net” sample from the repo? You could build it for windows, add it to steam and see if the overlay works. If you don’t have problems with the overlay in general, then this will work.
So like I said, there’s something particular I’m doing in my game that’s somehow blocking the overlay… I’ll just start adding stuff one line at a time to this new empty project and see what it is.
Please check your MonoGame reference. It seems that you need to rebuild the nuget package.
Yeah, you just need to setup your own windows build. All the necessary libraries for the windows platform are included:
In this case I just can give some general tips from my side:
The overlay gets injected only when the graphics device was successfully created before and the SteamApi was initialized afterwards with SteamAPI.Init().
Seeing the gameoverlayui.exe in the task manager is the best and easiest way to check if the overlay got successfully injected. If it’s not there, then the overlay was not injected. If you would just encounter rendering issues, then you would still see the gameoverlayui.exe task.
If something blocks the overlay in your code, then it has surly to do with something you did with the graphics device or maybe you are creating multiple windows.
Make sure that you first do everything what is needed for your graphics device initialization and check that the back buffer has the same size as your actual viewport.
So, basically you just need to check those things, because other stuff like game logic couldn’t brake the overlay.
