I'm doing a phone app with some animations and they look really clunky on the emulator. I don't have a phone yet so this is the only way I can test my app.
Sometimes the animations start late (up to a second after user input) and the they are almost always very jagged. Far from the smooth fades and transitions that I've seen on the interwebs. I'm not using anything hairy - just basic rotations and opacity fades on one or two elements.
Does anyone else see this in the emulator? If not, i guess I have a bug somewhere. If so, is there a work around? Should I bump the priority of the xde.exe in process explorer? Other?
Thanks!
This may be a consequence of gpu detection no working on your system.
You can verify this by checking if you can see the frame rate counters.
Jeff Wilcox – Frame rate counters in Windows Phone
Note the emulator system requirements here also.
Setup and System Requirements for Windows Phone Emulator
Related
I'm working on multithreaded game and targeting wp7 and wp8. I'm using background threads for network comunication and got stuck on problem that wp8 has huge perfomapnce issue when i have 3-4 background threads. Fps drops, for example if you touch rectangle and move it around screen with your finger it will move discrete not smoothly. But on wp7 all works smoothly and perfect. Whats wrong with multithreading in wp8? Are there any good practices to achieve good perfomance? Tested on lumia 920 and htc hd7
Workaround
Looks like promblem with new wp8 software update, but have no other device to test.
Microsoft declined to submit my application because I took a screen shot of the game which included the actual emulator.
Looking at this answer, the person says that I should us the snipping tool when I have made the phone emulator at 100%. And indeed, the snipping tools spits out an image of that screen at exactly 480x800 which is exactly what Microsoft wants. However, whenever I use the snipping tool, there is still the top black border of the WP7 remaining. I've looked at a few images on the Marketplace and other applications have it as well...I think. Some don't. Can anyone advice me on this please? How I can avoid getting penalised...again.
Will this suffice?
If you update to the Windows Phone 7.1 SDK and Emulator, the new emulator has a built-in screenshot function to take screenshots without these issues.
I have never had my app rejected due to a screenshot taken from the emulator, I can't say you wont have issues, but assuming everything else in your screenshot checks out; the images from the emulator are the correct size and should be approved.
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.
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'm writing some code to handle WM_GESTURE and WM_TOUCH events in Windows 7, but I can't figure out how to test it. I do my development in Boot Camp on a 17" Mac Book Pro.
So far, I have determined that the Boot Camp trackpad driver in Windows 7 does not generate those events, and this generic trackpad I found on Amazon.com that claims to be 'multi-touch' works as advertised, but not by creating WM_GESTURE or WM_TOUCH events. I verified this by using Spy++ to report the events; nothing with the WM_GESTURE or WM_TOUCH value was reported.
What kind of hardware is supposed to generate these kinds of events? At this point, I'm assuming it's only for tablet or mobile (Windows CE) hardware, but I'd appreciate any other suggestions.
I suppose there's another way to approach this -- I want to get functionality similar to Cocoa's [NSResponder swipeWithGesture:] and related methods, which report back swipes, rotation, and other gestures on the trackpad. WM_GESTURE appears to be the equivalent on Windows 7.
An other option, which would require only another physical mouse device to work with, and should get you at least 95% of the way there is the Multi-Touch Vista project, which can emulate up to 256 touch points using physical devices - thus the need for an extra mouse, or two since it can be awkward to simultaneously work with a mouse in one hand and trackpad with another.
There are several monitors out there supporting touch with Windows 7. For example: Acer T230H.
HTH
Wacom makes several touchpads that support multitouch; a particularly inexpensive version is the Bamboo Touch. This gives you touch without having to buy another monitor - although it doesn't give that direct interaction feeling.