Adobe Air Rendering/Input Issues (w/ Steam Overlay)
I am in the process of porting a Flash Player-based game over to the Desktop (OSX and Windows) via Adobe AIR (3.1). The porting to AIR itself has gone rather smoothly. The one wrinkle I've been dealt is that the game will be distributed over the Steam network. In order to interact with the Steam Client, I've had to write a native extension to expose the Steam SDK APIs to AS3. The native extension support has been implemented for both platforms, and I have the application launching and communicating with Steam as desired.
The area I've run into trouble is dealing with Steam's Overlay, which renders overtop of games when it is activated. Essentially, when a game is launched, the Steam Client suspends the process in order to hook its Overlay library up to either D3D or OpenGL. Initially, the overlay failed to appear at all as the AIR application descriptor had the default rendermode set to "auto." However, once I switched the rendermode to "gpu" the Overlay would appear as desired.
On the OSX side of things, everything works as expected. I can toggle in and out of the Overlay just fine. On the windows end of the spectrum, I've hit a bit of a problem when I activate the Overlay. Specifically, when the Overlay is enabled (it's rendering overtop of the game) and I either move the mouse or generate keyboard input, both the Overlay and the game both "freeze" (rendering stops) for 2-3 seconds. This problem has occurred on 4 of 5 windows machines (2 XP, 3 Win 7) we've tested on. Naturally, I first contacted Valve about the issue since this only occurs when the Overlay is enabled. I've uploaded both the OSX and Windows builds for their devs to debug; however, my contact suggested I find out more about AIRs rendering/input as well.
Here is a snippet of a post with a Steam Dev detailing how the overlay works:
The requirements for the overlay on Windows are as follows:
1) Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
2) Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
3) Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.
It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring.
Does it sound like any of the requirements above would cause a problem with AIR rendering or input? Will AIR's rendering/input implementation cause problems with any of the requirements above? How frequently do either Present/SwapBuffers get invoked? Are the calls dependent on input or actual game rendering? Naturally, I don't know the internals of either AIR or Steam's Overlay library, so I'm not sure how to really proceed outside of asking questions. Any help at this point would be very much appreciated! This is the last issue I'm trying to get through so that we can ship!
Oh - one other thing to note is that when I open the Task Manager with the game running, the cpu usage is roughly 75-80%. The cpu usage remains the same when I first activate the Overlay. However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to 0-1%. This made me think there may be some kind of a mutex/lock/semaphore contention occurring?
Thank you for your time,
Josh
AdChoices