After watching a little bit of the summit keynote I kind of heard conflicting reports about it, but is it official that XNA is being dropped for WP8? I'm guessing since the future version of WP supports previous generation of apps that this is probably not true.
If it is though is using C# even an option for games or is C++ with DirectX the only way to go?
the official wp7dev twitter account had this to say too
"XNA Framework apps are fully supported in WP8. The new WP SDK will support building XNA Framework games for both WP7.x & for WP8"
https://twitter.com/wp7dev/status/215513026374270977
Personally given the lack of XNA updates or information and the lack of any Metro support on windows 8 I'm staying a little skeptical until I see an SDK and the publishing rules.
Mary Jo Foley had this to say about that:
Microsoft officials have said the XNA tools/runtime environment used primarily by game developers isn't supported on Windows 8. On Windows Phone 8, XNA is "supported," so existing Windows Phone games will run. But Microsoft's advice to phone developers going forward, just like it is for Windows 8, is to use native code, meaning C and C++, to write games.
As the public WP8 SDK is now available, I can confirm that you cannot develop XNA apps for the #WP8 platform directly. You can only target the WP7 platform with your XNA apps and they will run on WP8 devices just fine.
I'm sure it's too early to speculate on this at this point, we'll see when the SDK is released. But from what I've seen so far - I would say yes, XNA might not be officially supported WP8 and onwards (read - new features will probably only be available via the DirectX interface, but existing features will continue to be supported). However, according to this thread, games that use Monogame to run on Windows 8 metro will pass certification. So in one way or the other, the platform will not die.
Edit: I just noticed this tweet from Shawn Hargreaves: Windows Phone 8 runs all 7 apps including XNA ones. We're adding new features (native code, D3D) not taking away old ones
I've been working on and off on an XNA game that I had started with VS2010 & WP 7 SDK, and later upgraded to 7.5 (Mango). I loaded up that project in VS2012 and the WP8 SDK and it ran just fine, compiled with no errors and ran smoothly.
As previously stated, XNA projects in VS2012 and the WP8 SDK can only target the WP 7.1 platform. On the upside, all phones running WP 7.5, the upcoming 7.8 and WP8 will run your game without any issues. From that point of view, XNA is fully supported in the WP8 SDK, on WP8 devices, but these WILL NOT be WP8 projects.
By not being WP8 projects, the downside is that you CANNOT use WP8-exclusive features, such as:
In-app purchasing / micro-transactions (this one hurts XNA devs the
most)
Your games will always be 800x480 since you need WP8 projects to support higher resolutions. Your XNA games should automatically scale up when run on devices with a higher res
Exclusive WP8 networking features & APIs, including Bluetooth and NFC
Speech and voice recognition APIs
Your XNA game cannot register a protocol extension for app-to-app communications
New Live Tile templates
The dev highlights for WP8 are on the wpdev blog at http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/11/05/windows-phone-8-developer-platform-highlights.aspx.
Related
I have a Windows phone 8.1 Silverlight application.
Now I need to make it run also on windows 10 phones and tablets. I checked and the app is available on windows 10 phones, even if deployed for windows 8.1 but it seems like I can't install it on windows 10 tablets.
My question is pretty simple:
Is there a "fast way" for converting the 8.1 project to UWP?
Can I deploy my app for tablets without re-writing all the code?
Thanks all
This question is oddly similar to one that I answered just yesterday. It's not really a duplicate so I will restate the answer here along with a link to the other question (1)
Unfortunately there is no easy and fully automated way to port your Silverlight app to UWP mostly because the API footprint has changed and updated between the 2 platforms. There are a lot of similarities but also a lot of breaking changes that require some manual changes.
here is Microsoft's guidance for this particular upgrade path.
From the article above:
Note This guide is designed to help you port your Windows Phone Silverlight app to Windows 10 manually. In addition to using the information in this guide to port your app, you can try the developer preview of Mobilize.NET's Silverlight Bridge to help automate the porting process. This tool analyzes your app's source code and converts references to Windows Phone Silverlight controls and APIs to their UWP counterparts. Because this tool is still in developer preview, it does not yet handle all conversion scenarios. However, most developers should be able to save some time and effort by starting with this tool. To try the developer preview, visit Mobilize.NET's website.
[1] Can a Silverlight out-of-browser app be converted to Universal Windows Platform (UWP) app?
When I create new Windows Phone project I have an option to create a "Windows Phone" or "Windows Phone Silverlight" app. I know that they have different runtimes and different APIs.
I was under the impression that Microsoft wants to unify Windows and Windows Phone platforms so why is there even a Silverlight version? What benefits does it bring?
Also, if I want to create an app just for Windows Phone and never have plans to bring it to Windows, what should I choose, Silverlight or Windows Phone?
I'd suggest you go with "Windows Phone" (non-Silverlight). It's the new API, which works for both Windows and Windows Phone. At some point you may want to port the app or create a new one for Windows and you'll already know the API (and porting will be way easier). Also, the new API will most likely get more updates and features added, and at some point you may even be forced to update to it (either because the old one is no longer supported, or because it does not have some features that you need).
As it was said in the other answers - the Silverlight option is there only for backward compatibility and is likely to be phased out in time. That is - it's good if you already know the API and have many libraries (yours or others) for WP Silverlight, but if you're just starting - you'd better go for the new technology.
Edit
There is one other thing to consider before choosing between the two types of apps. Some features are only available in a Silverlight app, and others (smaller amount) - only in a Xaml app. Here's an article with some info on the differences: Migrating your Windows Phone 8 app to a Windows Runtime XAML app
Windows RT Xaml is quite new and People have to generate some knowledge first.
Silverlight for phone has been around for years and there's a load of tools available: Phone Toolkit, diverse Controls, etc.
Just killing it off would have hurt many developers who built up intellectual property over a long time forcing them to start over.
When starting a project with Silverlight you will have more things around that help you get stuff done.
When starting with WinRT Xaml, you will have better performance, but will have to figure a lot out by yourself.
So the Silverlight option is there to not throw of Silverlight developers.
I recently started a new project on WinRT Xaml and my experience was that I had to recreate a lot of common tools like Caches, etc. But also a lot of things that were in Toolkits previously are now part of the platform itself. Also, when moving over to Windows 8, you get to share a lot of code which is nice.
Unifying the environment(s) would be ideal. In my opinion, it hasn't been very successful. At one point in time, you could only develop under Silverlight, so what you are seeing is just a newer version of the same thing to keep backwards compatibility as well as to keep Silverlight's developers happy. In the future, it will probably be phased out. Plus if you want to support older Phones, Silverlight is basically your only choice (you'll be surprise, how many WP users haven't updated their 8.0 to 8.1)
There really isn't any other real benefit of Silverlight other than maybe the Windows Phone Toolkit which has been tremendously useful (you can see how many SO's answers rely on this simple addon). Once the universal runtime gets fleshed out to the point where the documentation reflects what's actually available -- then I think it would be the default project for developing in Windows going forward.
If you're just starting, I would use Silverlight the knowledge based is much greater. After you get use to the WP environment then switch to runtime.
I have a Windows Phone 8.1 Silverlight application which is in the store now. Since i see that Microsoft is moving all the attention towards WINRT and Universal Apps, i suspect that there will be limited or no support for Silverlight Apps in Windows 10.
There might be a tablet project that i might roll out for the same project in the future. So i am in the dilemma to convert the Silveright projects in my solution to WINRT or convert them into Universal Apps.Also, i hear that converting to Universal projects are pretty hard as well.And I understand that the bulk of the work will be in porting the UI to Hub Style UI.
Any ideas? Comments on the best approach to take here.
A WinRT app is a Windows only app (not for Phone). Other than that, WinRT and Universal apps are quite similar. They have the same namespaces, classes, controls... almost everything. You can use many WinRT libraries in Universal apps without any problem. And so, porting to them is generally the same, too.
Windows Store and Windows Phone apps generally need different UI anyway, so you would have to work on that, no matter what you do.
One difference is that a WinRT app would work on Windows 8.0 and up, and a Universal app would require Windows 8.1 (or WP 8.1 for phones). Actually, a Windows 8.1 app IS a Universal app. Just like a Windows Phone 8.1 app (not the Silverlight variation) is a Universal app.
I'd recommend porting to a Universal app as you would get used to working with these apps, and they work on both platforms (Windows and Phone). For any future project, that's the way to go.
In the company I work for, we switched to Universal apps a few months ago. Figuring out what UI we would use on both platforms and how to do it properly, as well as porting our existing libraries did take some time (not too much), but now making a new app and supporting both platforms is very easy. So, for me, that's the way to go.
It is quite unlikely that Microsoft will stop supporting Silverlight Apps in the Windows 10 version for phones. Even WP8.1 still supports XNA Games from the WP7.0 era.
Depending on the APIs you are using in your libraries the majority of changes when converting from Silverlight to WinRT will be on the UI side, e.g. if your Silverlight App already uses the LocalStorage-APIs instead of the IsolatedStorage-APIs that won't even have to be changed.
My advice would be the following:
evaluate wether all functionality you need is supported in Universal Apps (some functionality is currently only available in Silverlight Apps)
evaluate wether the actual APIs you are using are supported in Universal Apps or need to be replaced (IsolatedStorage => LocalStorage, etc.)
Armed with that knowledge I'd guess you will be able to better plan on when to port your App to the new APIs. If a tablet version is likely in the future and all required APIs are supported in the Universal App Model porting sooner will likely require less effort than porting later.
If anyone has developed WP apps before you know that you can't pass certification if your app stops music that is currently playing without the users consent.
I did see this question here which might have worked for WP7 apps but it apparently doesn't work for WP8. I assume it doesn't work because the WP8 OS doesn't support XNA (It is only backward compatible, and if you developed the app using 7.1).
Has anyone come across the solution for detecting background music in WP8.
I believe checking for MediaPlayer.GameHasControl is what you're looking for. Use that property and other members of MediaPlayer to satisfy application certification guidelines 6.5.1 Here's an end-to-end example of how # http://henry-chong.com/2012/02/pro-tip-including-background-music-for-your-windows-phone-app/
BTW, 6.5.x application certification requirements don't apply if your app is a Music+Video app. That's one way to address 6.5.1 :)
I believe that Microsoft.Xna.Framework.Media.MediaPlayer.State is still supported in Windows Phone 8 (MSDN source):
You can reference and use the following XNA Framework assemblies in
apps that target Windows Phone OS 8.0:
...
Microsoft.Xna.Framework.Media.dll
...
Im trying to create a media player (in C# .net 4.0) that will work on windows XP (SP3), vista and 7. Normally I would just go the easy way and use WPF's own MediaElement, but since that relies on Windows Media Player 10 or newer, that wont work as Windows XP SP3 may only have WPM9.
First I tried downloading Jerimiah Morill's WPF MediaKit sample application, but this used the EVR which wont show on my test machine (a Windows xp SP3 only with default codecs and default programs, plus the various .Net framework installations). I also downloaded the binaries and tore these apart, creating a new project only with reference to the DirectShow-dll and the bare minimums from the WPF mediakit, this time with no reference whatsoever to EVR. Still no luck. This i'm having a hard time understanding - should'nt even Windows XP be able to play movies using VMR stright out of the box?
I found some samples of media players where one of these works. This one is called DxPlay and uses directshow's graphbuilder, but is built in winforms, has some rather raw-looking code, and will not scale, seek, handle audio, and in general seems rather sketchy.
So, Is there any easy way to create a media player that will play on all the mentioned platforms without pushing WMP10+? I had high hopes for WPF MediaKit, but something is preventing it from playing on Windows XP SP3 (any solution to this would be very interesting).
Thank you very much in advance!
-ruNury
I would try to wrap VLC media player in your .Net project.
Here are some .Net projects that might help you:
http://vlcdotnet.codeplex.com/
http://sourceforge.net/projects/libvlcnet/
http://www.codeproject.com/Articles/109639/nVLC
MSDN suggest EVR (Enhanced Video Renderer) for video output in systems where it is supported: Windows Vista and later. With its introduction, its predecessors - Video Mixing Renderer filter (versions 7 and 9) were cut on smooth scaling of video. Video Mixing Renderer 7 is also less capable in terms of customization, however it consumes far less resources (does not use Direct 3D) and you can output way more videos at once.
Your standard solution here is to support both VMR and EVR output and use the latter starting Windows Vista, fall back to the former otherwise.
EVR is "unofficially" installed in Windows XP with .NET runtime and can be used with an instantiation trick: you the respective DLL is not COM registered and you cannot create an instance using CoCreateInstance API, however you succeed if you do CoLoadLibrary, DllGetClassObject and friends.
For C# development you typically consume DirectShow through DirectShow.NET Library.