SteamOverlay only works in fullscreen mode (also doesn't work on Mac)
FlashGameDev opened this issue · comments
Hey there,
First off, thank you so much for creating this project. It has been a life saver. We are currently having an issue with the Steam Overlay methods however. It appears to only work when the client is in full screen mode, i.e.
stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
Anytime the client leaves fullscreen mode the overlay stops working but none of the methods return any type of error codes
trace("overlayenabled: " + m_steamWorks.isOverlayEnabled());
trace("activateGameOverlay: " + m_steamWorks.activateGameOverlay("Friends"));
both returns true. Also the
case SteamConstants.RESPONSE_OnGameOverlayActivated:
trace("RESPONSE_OnGameOverlayActivated: " + e.response);
break;
Is returning success. It just seems like something is broken. Additionally the steam overlay is not working for Mac users at all (even in fullscreen mode).
Would love to hear back from you, really hoping to get these issues solved!
Thanks again!
Anyone still developing on here?
Ventero does still maintain this as far as I know, he's probably just busy
at the moment :)
On Wed, Jan 14, 2015 at 8:01 PM, FlashGameDev notifications@github.com
wrote:
Anyone still developing on here?
—
Reply to this email directly or view it on GitHub
#15 (comment)
.
www.fortressofdoors.com -- Games, Art, Design
As @larsiusprime already mentioned, this project is still actively maintained, I just don't have much time to look at it during the week.
Regarding your issue: Due to the way the Steam overlay works, it only shows up if you have something in your application that makes AIR use hardware acceleration for its rendering. As you have noticed, one way to achieve this is by setting the display state to fullscreen.
Another thing you can try is calling Steamworks.addOverlayWorkaround(stage, true); during application startup. This adds a constantly "rotating" pixel to the top left corner of the stage, which should force AIR to use hardware acceleration (not sure if that's actually the case though). Additionally, it also works around a redraw issue, where after closing the overlay some parts of it would remain visible. Let me know if adding this call solves your problem - if not, can you check if the FRESteamWorksTest application (build and run it by going into test/bin-debug/ and running build.bat and runWin.bat) has the overlay?
The overlay should also work out of the box on OS X. The only thing that's different here is that you actually need to start your application through Steam for the overlay to be successfully injected (or set certain environment variables, see test/bin-debug/runMac.sh). Again, if that doesn't solve your issue, please try the FRESteamWorksTest application (this time, you need to run build.sh and runMac.sh).
We have been using Steamworks.addOverlayWorkaround(stage, true); the whole time. It doesn't make the overlay work outside of full screen mode. I ran the example application and it has the same behavior, when not in full screen mode none of the overlay buttons work, once I click the full screen button then the overlay starts to work again. Is this not the same behavior for you?
I'm about to try the Mac testing, but the code is the same and the overlay doesn't work inside of steam. I will see if any of the environment variables change anything and also try the test application on Mac.
Can anyone verify the steam overlay works for them when not in full screen mode?
The behavior is indeed quite different for me:
On OS X, the overlay always works as long as Steam is running and the application (both standalone and through the debugger) is either started with the runMac.sh script or through Steam itself.
On Windows, the overlay works as long as the standalone application (i.e. FRESteamWorksTest.exe directly, not through a debugger) is started through Steam. Running runWin.bat through Steam doesn't work because then the overlay tries to inject itself into the cmd window. Not sure why the overlay doesn't work when running the application outside of Steam - I'm pretty sure that did work in the past.
We do our exporting through flash builder 4.7. Could that potentially cause problems? Maybe we aren't doing something right in the export. I will continue to investigate!
That shouldn't really make a difference. I assume when you built and tested FRESteamWorksTest, you used the batch scripts in test/bin-debug/, right? If so, then the overlay definitely should work.
Can you please do the following: Start an AIR application (either FRESteamWorksTest.exe or your own application) through Steam, wait until it's fully started up, while it's running make a copy of GameOverlayRenderer.log from your Steam folder and upload/paste that file here.
Thanks for helping us figure this out. I'm looking at the config.bat, build.bat and runWin.bat files but they are pretty confusing to me as we have never done any command line compiling of our AS3 code so please forgive my ignorance here. Maybe I should first explain how we set things up.
We added the FRESteamWorks.ane to our Native Extensions in FlashBuilder and followed the documentation you have about unzipping the ANE and putting it in the src directory. Then I copied the steam_api.dll, libsteam_api.dylib and steam_appid.txt into C:\Program Files\Adobe\Adobe Flash Builder 4.7 (64 Bit) which contains my FlashBuilder.exe file (took me a while to figure that part out). It sounds like something in the differences of what we have done versus your scripts are causing our problems but I may need some help in understanding what I need to setup to make these scripts work. I'll post questions about what I am confused about (it's a lot so I apologize).
config.bat
set "AIR_SDK=%USERPROFILE%\Documents\AdobeAIRSDK" - I don't know where this is located when installing flash builder.
set "FLEX_SDK=%ProgramFiles(x86)%\FlashDevelop\Tools\flexsdk" - I also do not know where this is located on a flash builder install
I noticed on the runMac.sh it has something dealing with gameoverlayrenderer.dylib which we have not done anything for in our flash builder setup. I'm guessing this might be the cause for the steam overlay not working for us. Can't run this file without getting config.sh working though.
Here is a copy of the GameOverlayRenderer.log
Sat Jan 17 20:37:14 2015 UTC - Module file name: C:\Program Files (x86)\Steam\gameoverlayrenderer.dll
Sat Jan 17 20:37:14 2015 UTC - GameID = 334230
Sat Jan 17 20:37:14 2015 UTC - System page size: 4096
Sat Jan 17 20:37:14 2015 UTC - Hooking SetCursorPos, GetCursorPos, ShowCursor, and SetCursor
Sat Jan 17 20:37:14 2015 UTC - System page size: 4096
Sat Jan 17 20:37:14 2015 UTC - Modules at GameOverlayRenderer.dll attach
Sat Jan 17 20:37:14 2015 UTC - 01: TownOfSalem.exe - (0X010F0000 to 0X01117000)
Sat Jan 17 20:37:14 2015 UTC - 02: ntdll.dll - (0X77790000 to 0X77910000)
Sat Jan 17 20:37:14 2015 UTC - 03: kernel32.dll - (0X755A0000 to 0X756B0000)
Sat Jan 17 20:37:14 2015 UTC - 04: KERNELBASE.dll - (0X771E0000 to 0X77227000)
Sat Jan 17 20:37:14 2015 UTC - 05: SHELL32.dll - (0X75770000 to 0X763BA000)
Sat Jan 17 20:37:14 2015 UTC - 06: msvcrt.dll - (0X76AE0000 to 0X76B8C000)
Sat Jan 17 20:37:14 2015 UTC - 07: SHLWAPI.dll - (0X75250000 to 0X752A7000)
Sat Jan 17 20:37:14 2015 UTC - 08: GDI32.dll - (0X764E0000 to 0X76570000)
Sat Jan 17 20:37:14 2015 UTC - 09: USER32.dll - (0X76680000 to 0X76780000)
Sat Jan 17 20:37:14 2015 UTC - 10: ADVAPI32.dll - (0X75190000 to 0X75230000)
Sat Jan 17 20:37:14 2015 UTC - 11: sechost.dll - (0X763C0000 to 0X763D9000)
Sat Jan 17 20:37:14 2015 UTC - 12: RPCRT4.dll - (0X76580000 to 0X76670000)
Sat Jan 17 20:37:14 2015 UTC - 13: SspiCli.dll - (0X75120000 to 0X75180000)
Sat Jan 17 20:37:14 2015 UTC - 14: CRYPTBASE.dll - (0X75110000 to 0X7511C000)
Sat Jan 17 20:37:14 2015 UTC - 15: LPK.dll - (0X75180000 to 0X7518A000)
Sat Jan 17 20:37:14 2015 UTC - 16: USP10.dll - (0X76A40000 to 0X76ADD000)
Sat Jan 17 20:37:14 2015 UTC - 17: msi.dll - (0X72D40000 to 0X72F85000)
Sat Jan 17 20:37:14 2015 UTC - 18: ole32.dll - (0X77230000 to 0X7738C000)
Sat Jan 17 20:37:14 2015 UTC - 19: IMM32.DLL - (0X769E0000 to 0X76A40000)
Sat Jan 17 20:37:14 2015 UTC - 20: MSCTF.dll - (0X770F0000 to 0X771BC000)
Sat Jan 17 20:37:14 2015 UTC - 21: gameoverlayrenderer.dll - (0X50BC0000 to 0X50D0C000)
Sat Jan 17 20:37:14 2015 UTC - 22: WINMM.dll - (0X74EB0000 to 0X74EE2000)
Sat Jan 17 20:37:14 2015 UTC - 23: psapi.dll - (0X769D0000 to 0X769D5000)
Sat Jan 17 20:37:14 2015 UTC - ----------------------------
Sat Jan 17 20:37:14 2015 UTC - Found GetModuleHandleEx
Sat Jan 17 20:37:14 2015 UTC - Game is using dinput8, preparing to hook.
Sat Jan 17 20:37:14 2015 UTC - Game is using D3D9 or D3D9Ex, preparing to hook.
Sat Jan 17 20:37:14 2015 UTC - hookDirect3DCreate9 called
Sat Jan 17 20:37:14 2015 UTC - IWrapIDirect3D9::CreateDevice hook called (type: 1, behavior flags: 46!)
Sat Jan 17 20:37:14 2015 UTC - Creating D3D9 renderer
Sat Jan 17 20:37:14 2015 UTC - Trying to setup input hook...
Sat Jan 17 20:37:14 2015 UTC - Set input hook...
Thanks again!
I got the test example working using the scripts. However the overlay isn't work at all for me now.
I had to comment out the SetEnv call for it to compile for me however. Could this be a sign that something is wrong and maybe a hint as to why the overlay isn't injecting?
I looks like I wasn't using the latest ANE. After swapping out the ANE it compiles now. Sadly the overlay still is not being injected at all.
I used your scripts and got the overlay working for Mac. The last problem I have is how to use the runMac.sh script when publishing to Steam. It would be great if I could do the export DYLD_INSERT_LIBRARIES command in flash builder somehow. Any chance this can be done? If not do you know of any way to setup these scripts to be run in Steam?
I got things working. Not sure why no one responded for over a month. I spent a lot of hours scratching my head and guessing about things.
To save others a lot of hassle I recommend you make an addition to the installation documentation. Users need to make sure their tag in the xml of adobe AIR is set to "direct". It defaults to auto, which was the reason it didn't work outside of fullscreen on windows and not at all on mac. Having it set to direct enables hardware acceleration. Without hardware acceleration flash will be rendered ontop of the overlay. I can verify that your adding a pixel solution does not fix this. It has to be the renderMode setting.
Hi there, sorry to reopen this closed issue. We have been finding some issues lately trying to implement this on a Mac and I thought you'd be of some help for sure!
We already managed to debug the game via the Flash Builder IDE itself, got rid of the 3500 issue and used the DYLD_FALLBACK_LIBRARY_PATH workaround proposed in a Starling forum post by creating a shortcut to libsteam_api.dylib in /usr/local/lib
So far so good, but we are on a last step here, and this is, the overlay. We can't manage to make it work, no matter what. We already tried running the runMac.sh script, added by hand the 'gameoverlayrenderer.dylib' in '/usr/local/lib', exported 'DYLD_INSERT_LIBRARIES' env variable via the terminal but none of these solutions work.
My question is: did you guys manage to show the overlay at any point of your development? I see @FlashGameDev ended up making it work running the script 'runMac.sh' but we need to do it via the Flash Builder itself, debugging right away. I'd be grateful if you could point me in the right direction.
Cheers!
@cgascons If Flash Builder allows you to set environment variables for your subprocess, you can just set them to the values runMac.sh sets them to:
FRESteamWorks/test/bin-debug/runMac.sh
Lines 9 to 18 in 52c0b3a
If /Library/Application Support/Steam/Steam.AppBundle/Steam/Contents/MacOS/gameoverlayrenderer.dylib exists, set DYLD_INSERT_LIBRARIES to that path, otherwise to /Applications/Steam.app/Contents/MacOS/gameoverlayrenderer.dylib.
You can avoid the /usr/local/lib the same way: Set DYLD_FALLBACK_LIBRARY_PATH to <path to your Steam SDK>/redistributable_bin/osx32.
If Flash Builder doesn't allow setting environment variables for your process, you can try starting Flash Builder in an environment that has these variables set.
Hi @Ventero , thank you so much for replying! I'm hoping we can get to solve this with your help.
Either I'm not setting properly the environment variables or it isn't working at all (most probably is the first one). I've filled up both DYLD_FALLBACK_LIBRARY_PATH and DYLD_INSERT_LIBRARIES libraries by editing my .bash_profile file in my $HOME directory, so now when echoing these variables I get this:
Christians-MacBook-Pro:~ cgascons$ echo $DYLD_FALLBACK_LIBRARY_PATH
/Users/cgascons/workspaceAIR/_SDKS/steam/sdk/export/redistributable_bin/osx32
Christians-MacBook-Pro:~ cgascons$ echo $DYLD_INSERT_LIBRARIES
/Users/cgascons/Library/Application Support/Steam/Steam.AppBundle/Steam/Contents/MacOS/gameoverlayrenderer.dylib
On a side note, notice that I had to access the library located in my $HOME folder instead of directly accessing to /Library/Application Support/Steam/Steam.AppBundle/Steam/Contents/MacOS/gameoverlayrenderer.dylib because that path does not exist, I had to add the ~ before the library to access it properly.
So I thought those environment variables setting were going to be enough to make it work, but it's not, since Flash Builder doesn't seem to be listening to them at all. In fact, if I delete the shortcut to libsteam_api.dylib from where I created it (/usr/local/lib) the app doesn't work at all, it returns the already well known error #3500 (The extension does not have a method...), on the other hand with the shortcut there the app initializes properly and everything seems to work fine (except the overlay, which I need to test my in app purchases).
I'm crossing fingers here to see if we can get this working soon, thank you so much so far for replying!
As of today I haven't still been able to manage to display the overlay while debugging from the IDE. I'd really appreciate a hand here, we are testing the microtransactions blindly and it's really being a nightmare.