Showing posts with label xna. Show all posts
Showing posts with label xna. Show all posts

Wednesday, 1 May 2013

Enable Azure Mobile Services for "pure" Windows Phone 7.1 Xna Games

     Recently somebody asked me for an advice on what library should he use to communicate with an Azure Mobile Service for an Windows Phone OS 7.1 and Windows 8 Xna game. My answer was, of course, the Windows Azure Mobile Services client library available on NuGet as I remembered that the prerelease version works also for Windows Phone OS 7.x applications.

The "problem" is that the library will not install if the game is a pure Xna Windows Phone project.

There are 2 (maybe 3 :) ) solutions to this problem:
1. Migrate your XNA project to an "Windows Phone XAML and XNA App" and on this type of project the client library will install correctly.
2. You could use a small hack in order to force NuGet to install the Azure Mobile Services client library on your XNA project. The hack is pretty simple:
  • open the YourProject.csproj file with an text editor (like Notepad) and add these 3 line (not sure if all 3 of them are needed but doesn't matter as it is only done to force the library to install):
  •  <SilverlightVersion>$(TargetFrameworkVersion)</SilverlightVersion>  
    <TargetFrameworkProfile>WindowsPhone71</TargetFrameworkProfile>
    <TargetFrameworkIdentifier>Silverlight</TargetFrameworkIdentifier>
  •  Visual Studio will see that the project has been modified so it will ask to Reload the project. Reload it (don't try to build the project as it won't), open the Package Manager Console and write:
     Install-Package WindowsAzure.MobileServices -Pre   
    the package should now install.
  • Reopen the .csproj file in Notepad and remove the 3 lines we've previously added, save and reload the project in Visual Studio. The project should compile correctly and you should be able to use the Azure Mobile Services client library.

The only thing that doesn't seem to work is make Visual Studio recognize the await keyword for the XNA project. You will have to use the ContinueWith syntax:

 void TestAzureMobile()  
{
todoitem item = new todoitem { Text = "Awesome item XNA" };
ms.GetTable<todoitem>().InsertAsync(item).ContinueWith((task)
=>
{
//do what you need here
});
}

3. Came to me while writing the post. Guess the most "elegant" way is to add an Windows Phone Class library to your project, add and use the Azure Mobile Service client library from the class library, reference the class library from your XNA project. Tried this one but the MobileServiceClient seems to fail initialization with 'System.TypeInitializationException'.

Take in consideration that the Azure Mobile Services client library is still a pre-release version in this moment so for the release they might fix/enhance it and you could install it on XNA projects without any hack needed (it is a PCL library).

Monday, 8 October 2012

Farseer Physics for Windows Store Apps using Monogame

  Last week I did a session on porting XNA Windows Phone 7.x games to Windows Store apps using MonoGame. I have to thank Dean Ellis from the MonoGame project team for all the help. 
 While XNA is not a framework directly supported by Microsoft for Windows Store apps the current version of MonoGame is compatible with Windows 8 and, the most important thing, the applications pass the WACK. There are already several games available in the Windows Store developed using MonoGame (Armed, Skiddy, Rune Legend and I guess there are more). 
   For the session I ended up using the Simple Animation sample but seeing how easy is to share the code between the platforms (Windows, Windows Phone,PC, MAC, iOS, Android, Playstation, Linux) I started looking for a physics engine. The most used Open Source physics engine seems to be Farseer Physics but it was too late to do the porting for my session. On Sunday I tried the porting and everything went pretty smooth. The only thing I've changed was the serialization/de-serialization of the "World" state. I compiled the engine and also the sample. For the Sample project the Content Project was compiled using Visual Studio 2010 (for the moment Visual Studio 2012 doesn't recognize this type of project) and added the xnb's to a Content folder inside the Visual Studio 2012 solution. 
 You can see the result in this YouTube video:


I've used SnagIt to capture the movie and it influenced the frame rate (when running without capturing the framerate is always at 60 fps). The test device was the Samsung Slate which has a powerful cpu. I would love to know if a WinRT device will be able to run at the . If any of my readers has access to a WinRT device please deploy the sample to the device and let me know if the framerate is as expected. For the sample you will have to use an external keyboard and mouse as the touch screen is not working in this version. I will try to fix it for the next release (the problem seems to be inside the MonoGame framework as I only receive the move event and not the pressed and released from the touch screen).
   
Use this link to download the full project (engine and sample): 

NAMASTE





Wednesday, 26 October 2011

WP7 A better InkPresenter using XNA

  Last week I was at SMAU Italia  together with Matteo Pagani giving a hand at Windows Phone 7 labs and having a good time with my friends at Microsoft. I also got the pleasure to meet Ben Riga. One of the attendees at the laboratory raised a really good question about the performance of the InkPresenter in WP7. He is using the control to capture a signature, but if you are pretty fast (usually people when they do their signature are fast) the result is "ugly" and not really usable. You won't get a smooth curve, but something like this:


 This screenshot is taken in the emulator, but on the real device the curve looks worst and it's easy to reproduce this behavior. I took this "problem" as a challenge (two nights of work and now the third to write the post) convinced that I can get better results with a mix between XNA and Silverlight, mix that in Mango is possible. T
 The main problem is the number of points returned by the event MouseMove of the InkPresenter control which is not enough points to draw a decent curve.
  The first thing I've tried in the XNA version was to use the TouchPanel.GetState() but I was surprised to see that I get the same number of sampling points as the MouseMove in InkPresenter. The things improved a lot when I've used TouchPanel.ReadGesture() with GestureType.FreeDrag. Using these sampling points as StylusPoints for the InkPresenter the situation improved a little:


 The black line is the one obtained with MouseMove and the red one is the one obtained with ReadGesture.The result is better, but not satisfying. The only way to further improve the result was to manually draw the curve without InkPresenter. I've have used BezierSegment to draw the curve. Without any processing this would be the result:


The new curve is the blue one which is better than the others, but it is still not smooth in some points. This is because a Bézier path is smooth if each endpoint and its two surrounding control points lie in a straight line. In other words, the two tangents at each Bézier endpoint are parallel.



There is more than one approach to solve this behavior and I've implemented two (with all the mathematics I felt back at the University http://en.wikipedia.org/wiki/B%C3%A9zier_curve). 

The first is an algorithm for Automatically Fitting Digitized Curves with the Douglas Peucker algorithm to reduce the number of points (http://stackoverflow.com/questions/5525665/smoothing-a-hand-drawn-curve).

The second one uses Bézier splines which creates the First and Second control points for each Bézier segment http://www.codeproject.com/KB/graphics/BezierSpline.aspx . 

With both algorithms the results are pretty good:


If you are interested to play with the sample you can change the following parameters:

double PhilipSchneiderTolerance = 0;
double PhilipSchneiderError = 4;
-used when the fitting algorithm is PhilipSchneider (run this sample http://cid-c27e99281f78a67a.office.live.com/self.aspx/Public/Simplify.zip on the desktop to understand what changes when you change the Tolerance and the Error)

 private bool _showPoints = false;
-shows or hides the points read by ReadGesture
        
private bool _showOtherCurves = false;
-shows or hides the InkPresenter curve using MouseMove and ReadGesture

private FitCurveAlgorithm _algorithm = FitCurveAlgorithm.PhilipSchneider;
-changes the fitting algorithm: None, BezierSpline, PhilipSchneider




P.S. The project still needs some working/polishing in order to be used in production, but that is the simple part so... HAVE FUN

NAMASTE

Thursday, 25 August 2011

Where XNA beats up Silverlight

   Finally a blog post. I am in the process of updating (it's more of a rewriting) Boxfiles for Mango. Till now I have rewritten the Dropbox library from scratch (took off all the dependencies Hammock, Json.Net and now it's pure HttpWebRequest) and developed a library for accessing Skydrive resources (it works and it is possible to list the folders and download the files mainly what I need to get the modified Office files back to Dropbox). Anyway the Skydrive API it's a mess for the moment and I really hope they will get a "clean" API. The current version of the Rest Api is usable only for contacts, photos and videos. I will post both libraries on Codeplex (very probable after I finish the update of Boxfiles). 
    So what is this post all about. One of the features of the new version of Boxfiles will be pinch to zoom. Searching on the web I have found the XNA and the Silverlight solutions. I've started with Silverlight and with pinch to zoom added the application would easily eat more than 90MB of RAM while the image window is opened.  Digging up on what was consuming so much memory it turned up that the image window eats around 40 MB of memory (also because I have enabled CacheMode="BitmapCache" in order to have a smooth zoom). This is an abomination for a simple page with one menu and an Image control displaying a file  of 3MB. I than remembered that, in Mango, Silverlight and Xna can "live" together. The feature was introduced for enabling Silverlight in Xna (menus and stuff) , but in this particular case I will use Xna in Silverlight. I've created a project where I can compare the pinch to zoom on both Xna and Silverlight. The results are not bad: XNA uses around 10MB while Silverlight uses 40MB and the pinch to zoom is much smoother in Xna (the sample starts with 10MB of memory occupied).




    In order to have a realistic comparison I've added an ApplicationBar to the Xna window and both of the windows have a Menu where you can force the GC to collect. While testing the solution I've found a really strange behavior (in my opinion it's a memory leak of the image control and maybe somebody from Microsoft should have a look into it): the Silverlight window, after the first launch, was not releasing 10MB of memory. In order to release the memory I had to manually remove the Image control from the ContentPanel and give it a null value.


ContentPanel.Children.Remove(image);
image = null;

If you play with the solution just comment the two lines located in OnNavigatedFrom (ImageSilverlight.xaml.cs) and you will see the leak.

Here is the Source Code

NAMASTE!