Delta Engine - Platforms

This device is currently planned for Milestone 2: Neptune. See the Roadmap for details!

Table of Contents [Hide/Show]

   Overview
   Device Information
   Deployment Steps
   Tips and Links
   Comments

Overview¶

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).

Edit

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.

Edit

Deployment Steps¶

Launcher Preview Video for Delta Engine v0.9.4 showing how to build the Blocks sample app:

TODO: More details about the deployment process coming soon

Edit

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 Launcher onto 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: http://jonas.follesoe.no/SimulatingMultitouchOnTheWindowsPhone7Emulator.aspx

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've capped 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:
- http://social.msdn.microsoft.com/Forums/en-US/windowsphone7series/thread/900924cc-2ad4-4b91-9bd8-92c87d36ad5b
- http://www.msteched.com/2010/NorthAmerica/WPH308

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:

http://social.msdn.microsoft.com/Forums/en-US/windowsphone7series/thread/b2430205-ca17-41ed-bae3-50c2a23ae2b4
http://windowsteamblog.com/windows_phone/b/wpdev/archive/2010/03/15/the-right-mix.aspx (see VerificationException when trying to use unsafe code)
http://jiglibx.codeplex.com/Thread/View.aspx?ThreadId=222718

Other useful WP7 links for the interested: