Table of Contents 

   Device Information
   Deployment Steps
   Tips and Links


Windows Phone 7 is currently (v0.9.1) one of our main target platforms we use for developing and testing our games, samples and tests. We have worked on Windows Phone 7 a bit in 2010, see our ZombieParty game released in 2010 in the first weeks after the WP7 came out, but most of our time is spend on the other platforms. While it is very easy for a .NET developer to just develop for the Windows Phone 7 (in XNA or Silverlight), your features and your code itself will get very limited to this particular platform, which is something we don't want for the Delta Engine. 

Instead of just developing directly for WP7, we do all development on Windows and then try to bring everything back to WP7, iOS, Android and all the other platforms via the Build System, which usually means we need to go through a lot of extra steps, handling all the content ourselves and providing tons of fallback code for unsupported features. In the end the benefits are pretty cool, applications just work out of the box on all platforms :) Contact us on the Marketplace site if you want to deploy to WP7 (all you need is a WP7 developer account from Microsoft).

In order to test and debug applications on your Window Phone you need to register you device for development.
To do this, you first need to setup a Window Live account and then join the Windows Phone Dev Center to buy a subscription.
When done, you're able to finally register you phone. Just follow this steps from the official Microsoft site.
For development you also need the latest version of the Windows Phone SDK, which is always available here.

Device Information

  • Windows Phone 7 Screen size: 800x480
  • Screen Size: 3.5 Inches
  • CPU: Around 1Ghz
  • GPU: A little weak for 800x480, otherwise comparable with iPhone 3GS-iPhone 4 nowadays.

Tips and Links

To test the Windows Phone 7 early and prevent incompatibilities, we recommend using the Delta Engine Windows XNA modules for Graphics, Multimedia and Input to get as much as possible fixed and solved on the Windows side.

Note: Performance should not be tested with the Device Emulator or in Windows, always try to get the package you get back from the Launcheronto a real device for testing.

MultiTouch in the emulator

Sadly multitouch testing is not possible with the WP7 emulator (which is plain stupid IMO), but if works just fine if you have a Windows 7 Multitouch capable monitor. You can also use a little trick by using the MultiTouchVista project, which supports multiple mice, web cameras and Wii remotes, pretty cool stuff:

Outdated (now can do 60fps with WP7 7.1 Mango update): 30 Fps cap:

  • From a microsoft guy (2010-10-08), but probably somewhere in the documentation as well: "Don't worry about us trying to hit 60fps, we'vecapped the XNA games display at 30 FPS. :)" This means we cannot achieve anything more than 30fps (since XNA just does not allow more, it seems it is also a limit the hardware developers just put in place for saving battery live and limiting the stuff the phone has to do), which is not so good for touch input, but otherwise still feels smooth.
    The Frame rate is 30 fps by default for Windows Phone 7. We cannot go above that on the device, it is capped at 30 fps (because of the way Microsoft has limited the specs for the hardware manufacturers and because XNA on WP7 is always limited by that 30 fps). We can go below 30 fps via Settings.Debug.LimitFramerateNumber for testing, the emulator could even handle more than 30 fps (up to 60 or 75 depending on the screen refresh vertical-sync), but that does not help us on the real device, so this engine limits the fps to 30 on WP7 as well!
    More information about this can be found at:

File access:

  • The Build System automatically converts all code that uses File.Exists or File.Open, new FileStream, etc. to FileHelper.Exists, etc. Otherwise you end up with a System.MethodAccessException every time you call some File method (Exists, open, delete, etc.). Instead use the content pipeline for content and the IsolatedStorage for settings and log stuff (see FileHelper on how that works).
  • Getting the current path (of the app) with e.g. "Directory.GetCurrentPath()" or "Environment.CurrentDirectory" is impossable (automatically mapped to the isolated storage via FileHelper.GetCurrentDirectory).
Note: Be aware that WP7 is tightly sandboxed, many things are not possible, including unsafe code. The Build System and Launcher will help you as much as possible and automatically provide fallback code if some feature is not supported. If you have your own code or unsupported library code, contact us in the Forum to get it sorted out: