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. Additionally, I have noticed 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 active the Overlay (which is desired). However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to roughly 1%. 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:
Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
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.
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."
After a little more prodding, the Valve devs profiled my application to determine if there was any specific problem occuring with the Game Overlay. Unfortunately, they were unable to find anything going on in the Overlay itself. This pretty much means that AIR on Windows doesn't like that the Overlay is blocking Win32 input messages. Here is the Valve dev's response:
"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.
It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.
Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."
I've posted on the Adobe forums, but haven't had any such luck over there. Mainly, I'm hoping that someone has either dealt with this before or has an idea about how I could possibly get around the issue. Any suggestions, comments or thoughts would be greatly appreciated!
As it turns out, there is an bug deep in AIR core framework that is the root cause of this issue. Adobe has confirmed the bug, and they are working on a fix for the Cyril (AIR 3.3) release. The status of the bug (#3089755) can be viewed in the Adobe AIR bug list.
In the short-term, I was forced to detect Windows messages that were being consumed by the SteamOverlay, and pass on fake messages to prevent AIR from locking up. I accomplished this by using the Windows API SetWindowsHookEx along with the WH_DEBUG and WH_GETMESSAGE hooks. This is definitely not a desirable approach, but was needed in the short-term until Adobe releases a fix.
Related
I'm using opengl es 3.0 API with the android studio ndk to create apps.
But I've encountered a very huge problem. I've created a demo app, all it does it change the background color of the screen from white to black and vice versa, every frame. And so when I go to minimize this app, I still see it rendering the background, mostly at the edges of the screen, and not in full color but still very strongly apparent. And it doesn't go away when I close the app, when I restart the device, or when I run "kill apps" on it. Only a factory data reset fixes the issue, so it's not easy for me to debug this.
This is the relevant code that I'm using for when the app is minimized and receives the APP_CMD_TERMINATE event:
eglMakeCurrent(engine->display,EGL_NO_SURFACE,EGL_NO_SURFACE,EGL_NO_CONTEXT);
eglDestroySurface(engine->display,engine->surface);
engine->display = EGL_NO_DISPLAY;
engine->surface = EGL_NO_SURFACE;
I've error checked that eglDestroySurface() is successful.
And I've put debugging messages in to make sure that the main draw loop is NOT executing when the app is minimized. But the problem persists and I don't know what to do about it. Thanks for any help.
UPDATE: well, no one has responded, and I still don't know what to do. Could it be related to threads?
UPDATE: Still can't determine what it is, but for some reason it's messing with the System UI. Willing to upload my entire source code somewhere if someone would be willing to go through this with me, as I'd really like to be able to continue working on my game engine.
Is it the "Strict Mode" developer option on the device settings, perhaps?
That one flashes the screen if an app is blocking.
It would explain why a factory reset changes behaviour.
The answer is not a solution here. The above comment by the user columbo was correct.
I've demoed switching from black to white at high framerates on 3 different android devices, and also my Linux Desktop, all via the openGL api, and it has exhibited this issue on all the devices. So what he said must be correct: this is a problem with LCD monitor technology itself. Interestingly, doing completely random colors does not cause this problem.
My Windows Phone XNA game calls Guide.BeginShowKeyboardInput to get the user's name. While the Guide's input screen is shown, if the user presses the Home or Search (hardware) buttons, the game is deactivated as usual - but if the user then presses the Back (hardware) button, the game should resume but it doesn't. Instead it shows the "Resuming..." message until Windows Phone gives up trying to resume the game and kills the process.
Please note:
My app is failing Microsoft certification because of this problem - I really need to fix it!
This only happens in my game when the Guide input screen is shown - when it's not shown, the game
resumes properly after being deactivated.
This problem only occurs when the game is run on WP7.x (verified problem on WP7.5 and
WP7.8) - although the game seems to resume properly on WP8 devices.
I've created a blank XNA game project, called Guide.BeginShowKeyboardInput and tested it using WP7.x devices, and this problem-behavior doesn't occur.
I've tested the game without enabling Music & my Trial License manager (they use timers) and it still does this.
Exact same behavior occurs in the emulator (resume-failure on WP7.x emulators, works fine on WP8
emulator)
I used threads to asynchronously download content during the loading screen - but they already completed and exited.
I don't believe other threads are running, although this seems like
it could be a thread-blocking issue.
Any other ideas on what could be blocking the game from resuming when the Guide.IsVisible or how to debug/resolve this problem?
The solution to this issue was simply to NOT use SuppressDraw when dealing with any operation that passes control outside of the app, e.g. Launchers, Choosers and the Guide.
Have you tried calling "Guide.EndShowKeyboardInput" in either the Deactivating or closing events?
So that the guide is closed before the app suspends, you do get 10 seconds to suspend so this might be worth looking into.
If you want the guide to re-show on resume, then in your state saving code just have a flag and open the guide if it's set.
Quick question -- if I code something to respond to "MouseLeftButtonDown" such as the pushing of an image, if I leave the code the same way when I ship the app, will this directly translate to the user pushing their finger down on the same spot, and thus fire the code?
Do I have to change the MouseLeftButtonDown to the gesture listener for this to translate, such that MouseLeftButtonDown is only used in place of non-touch monitors when coding to test things?
THanks!
As corrected by Matt in the comments, the MouseLeftButtonDown event is not the same as an image tap. However, the result would be the same in that if your code works on the emulator, regarding the tapping, then it should work on the device.
You should try and get your app running on a device though as there can be things easily overlooked in the emulator. For example, performance can decrease on your phone since it's likely to be quite a lot less powerful than your PC. Therefore, if your app is performing fine on your PC (emulator), it doesn't necessarily mean you'll get the same speeds on the device.
I am looking for some advice/input on writing a device driver. I have never written one for windows before, let alone for bluetooth.
Can you recommend a book or website or something to get me started? I have the windows driver kit, and the examples therein but with out some place to start I am dead in the water.
The specifics: My friend gave me his mac Magic Mouse. I have a windows 7 machine. With the mouse set up as just a generic HID device it works ok as a two button mouse with no scroll, the motion is smooth and the acceleration what you expect in a windows mouse.
The mouse actually has a fairly good lpi resolution, making it pretty sensitive. There are mac drivers available, extracted from bootcamp. They kind of work. The cursor will randomly freeze or stop responding to the mouse's movement, which is buffered, and then leap once whatever has caused the stall stops. As an added touch the mac drivers make the cursor move like it would on a mac, with that logarithmic acceleration, that will completely throw off any windows user. With the driers you get vertical and horizontal scroll, but that's it. There is no multi touch functionality, and you can't change any of the behaviors, like acceleration. There isn't multiclutch for windows, or other 3rd party software for a multi touch mouse.
So I figured I would endeavor to make my own drivers and multi touch functionality in windows for this thing. I know mac will never support it properly under windows and windows won't write there own drivers until there is a reason.
Also if any one knows of any one else trying to do the same or similar things, point me to them.
Is it possible to track the accelerometer value while under the lock screen?
I managed to write a simple application which counts from 1 up to 100 using a timer which fires an event on which I increment a counter.
But when I use register a handler for the ReadingChanged event of the accelerometer it will not be fired anymore once the screen has been locked. Even if I unlock the screen again I will have to readd my handler.
the msdn documentation tells on the one page:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff941090(v=vs.105).aspx
"Valid reasons to disable idle detection in Windows Phone OS 7.1 applications include ones where core functionality continues while the phone is locked (for instance, an exercise tracking app)"
but the sensor api also tells:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202968(v=vs.105).aspx
"The Sensor APIs cannot be used while the application is running under the lock screen. For more information, see Idle Detection for Windows Phone. The Sensor APIs also cannot be used in background agents. For more information, see Background Agents Overview for Windows Phone"
I hope they will change the api soon, because of that it is not possible to write any good sleep tracking / sport tracking applications ... :(
I was helping a guy with this a couple of days ago. He had an app that tracks GPS and accelerometer data under lock screen.
Turned out the app accelerometer data stopped tracking when under manual or auto lock screen.
There may be an issue here to be looked into.
Under lock screen it is a good idea to minimise power usage... disable all uncessary code, like ui updates. My understanding of one the motivations for idle detection and running under lockscreen being opened up during CTP was in response to a lot of feedback from developers of map/tracking apps that basically need this for their app to be of any use.
I'm not sure of the usage case where you'd want to use the accelerometer under the lock screen.
Apps typically run under the lock screen when you need them to do something when you're not interacting with the device. e.g. playing music or downloading a large file.
If you wanted accelerometer data I'd assume that the device is being held and, therefore, presumably, looked at. Given this, why would you therefore want to run under the lock screen?
That being said, if you had a good reason to do so, you should still be aware that:
when your application runs under a locked screen, it ... must minimize
power usage
(from the Marketplace Certification Requirements.)
In my understanding, reading values from sensors is not minimizing power usage.