What is the relationship between XNA and XNA for Windows Phone?
Is that latter a true subset of the former like the .NET Client Profile?
Mostly a subset (like Silverlight vs Silverlight for Windows Phone)?
Or is it simply a similar API like WPF vs Silverlight?
They're identical in terms of the XNA API, and both are developed using the same download, typically XNA + C# + Visual Studio.
There are differences in what each platform supports though. For XNA in general I'd always consult Shawn Hargreaves blog first, and this article is most relevant: http://blogs.msdn.com/b/shawnhar/archive/2010/03/10/xna-game-studio-on-windows-phone.aspx
The biggest differences vs Xbox 360/Windows are display resolution, input methods available, and the fact that Windows Phone 7 doesn't support programmable shaders (so you can't write your own velvet/Fresnel shader for WP7, but you can for Windows and the 360).
Performance also varies: on Windows XNA performs well without much effort as it runs on the full .NET Framework. On the 360 and WP7, it runs on the .NET Compact Framework, so whilst you get the full XNA API you only have access to a subset of the full .NET Framework (though in a typical game you won't miss much of it) plus its garbage collection is shocking so depending on your game you may really have to watch memory allocation.
According to the following MSDN page, it's a subset of full XNA:
http://msdn.microsoft.com/en-us/library/gg490768.aspx
If you're considering writing XNA games for Windows 8, you may want to hold fire, as it's none too clear if XNA is still a long-term strategy for Microsoft (at least, if their comments at the recent BUILD conference are anything to go by):
http://www.rabidlion.com/2011/09/opinion-why-xna-isnt-dead-yet.html
Related
I was wondering if it is actually true that Microsoft is discontinuing XNA and Silverlight. If this is the case? What shall I learn to make applications for Windows Phone? What shall I learn to make simple/easy 2D based games (not c++)?
What are the alternatives with Windows 8?
Cheers.
There is no official announcement from Microsoft that says they are discontinuing Silverlight/XNA.
Of course, a lot of us have our own reasons to believe that Silverlight is dying. I would not say the same about XNA. At least not yet :-) Don't forget XBox.
For the next version of Windows Phone (8), application programming model is going to be based on/same as Windows 8 (Win RT). And they have been promoting DirectX as a technology to develop games for Windows 8 (WinRT). XNA is officially not supported in Metro Mode.
To program games in DirectX, C++ is not the only option. Managed DirectX can be used with C#/VB. You can look into that.
And if you know Silverlight, your understanding on XAML would really help you a lot with new Metro Style apps (Phone and Windows). So, you don't have to worry about that part.
It's hard to say something about a rumor, but in this case the best thing that you can do is to stay in contact with Microsoft and its forums or social network.
For example http://channel9.msdn.com/Forums/Coffeehouse/XNA-in-Windows-8
Windows Phone 8 will surely introduce a support for DirectX and C++, XNA is a subset, more or less, of DirectX, if Microsoft will introduce DirectX in its phones i see no point for keeping XNA; Silverlight is a technology that will never succeed at this point, even Flash is dead, you can imagine what is the situation about Silverlight that is a really really really small player in this market and it's not even portable.
For games it's better to use XNA, because eventually you'll start to create 3d games.
Silverlight is more adapted for common applications, like notepad, browser and other stuff.
And again, if you want to create games, learn more Xna.
As there is no official statement yet, it's hard to say what will happen with those platforms. If you want to create games, you might consider using MonoGame.
What is MonoGame?
MonoGame is an Open Source implementation of the Microsoft XNA 4
Framework. Our goal is to allow XNA developers on Xbox 360, Windows &
Windows Phone to port their games to the iOS, Android, Mac OS X, Linux
and Windows 8 Metro. PlayStation Mobile development is currently in
progress.
I had a demo of a few games made in MonoGame on Windows 8 last week and I gotta say I was pretty impressed.
Some articles point to Windows 8 development being HTML-based instead of primarily using native code like C or C++ (as it has been until now) or .NET (as now, or even more so as it would have been in Longhorn, but never was.)
Is this true? Will the core APIs be accessible from Javascript then? What is the primary API / framework for Windows 8?
This is worth asking. When Windows 8 was demonstrated in June, a couple of comments by the presenter scared quite a few developers - or at least turned the Internet into panic mode. I'm surprised this question hasn't been asked here before.
The best article on the topic I have found is Windows 8 for Software Developers on Ars Technica.
The short answer is: it will remain the same.
The long answer is: it will remain the same, but several things will be added. You may want to pursue using those if you're willing to bet on new Microsoft technologies. One particularly interesting one is WinRT, which is a new object-oriented native code API exposed through COM, which is supposed to be a new version of the old flat Win32 API. Details are in the linked article.
It is very, very, very, very unlikely that anything that already exists, especially based on Win32 or .Net, would be removed. That means your existing programs written in .Net or native C++ or Delphi will continue to work fine. It is also unlikely that the primary development platform will be HTML. More likely is that HTML applications will be encourage for specific scenarios - perhaps touchscreen, kiosks and tablets.
I'd encourage you to read the article I linked to above - it covers this in far more detail than any answer here can.
There are three ways to develop for Windows 8, and they all access the same underlying API, the Windows Runtime.
Use C++ and call WinRT functions much like calling Win32 APIs back in the day (you know, yesterday)
Use C# or VB and call what appear to be .NET methods (but aren't)
Use Javascript and call WinRT functions
The UI is built with XAML using a pretty reasonable designer. More details are still coming out: check http://channel9.msdn.com/Events/BUILD/BUILD2011 for videos with detailed coding demos. http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005 is not a bad starting point.
There are 3 language/framework combinations that are all equally supported:
C++ and XAML
C#/VB and XAML
JavaScript and CSS/HTML
All are first class ways to write Windows 8 Metro style applications. Windows Runtime provides direct access to each of these languages and so choice of development environment can be based on familiarity or feature set of the language and not on restricted availability.
Update: I forgot one: C++/Direct3D (for games).
The original quote, in the context of writing a tablet desktop weather gadget application, is that the application uses "our new developer platform, which is, uhh, it's based on HTML5 and JavaScript."
The demonstrator never said a gadget is the preferred type for applications (How many Vista sidebar gadget or Windows 7 desktop gadget have you written in your life? Even when you can write them in simple HTML!), or the platform is the preferred platform for desktop weather gadget applications (How many animation control have you add to your application with video playing requirement? It is THE control used by Windows Explorer to display video!).
Today, after spending a few minutes playing with Windows 8 developer preview, I found that you can use Expression Blend 5 to easily auto-generate metro-styled applications in HTML and Javascript. Also in Visual Studio you can create exactly looking applications in Silverlight. :)
I am very excited!!! Go Windows 8! :)
I am developing a relatively simple .NET class library mainly using basic value and reference types. To save code duplication, I would like to export to 1 DLL which could be used by both Windows PCs and Windows Phone devices? Is this possible? As far as I know, all methods are compatible with the .NET and Compact .NET Framework.
Yes, as long as you stick to the Compact Framework subset, it will work. Check out this MSDN article on that same topic.
Quote:
The techniques and principles
discussed in this article can be
utilized when writing cross-device
code—applications that target Windows
devices with differing form factors
(different screen sizes, orientations,
touch screens and so on).
Almost all Windows applications with GUI (WinForms or Native) use GDIPlus.
But this technology is quite old, and it shows many limitations.
Alternatives are WPF, or Silverlight, Flash? But Developer Tools like Visual Studio and Delphi still use GDIPlus as reference.
When will this change? ANd moreover: will there be a portability? Like the Delphi VCL will in future be ported to a new technology maintaining backwards compatibility? (for ex TButton is GDI, in future it can be something else).
UPDATE: Maybe my question can be stated as "will future OS render GUI Widgets without GDI+ but using newer technology, a kind of builtin SIlverlight/Flash?"
For native programs, WPF has already replaced GDI+ in my view, but since GDI+ and WinForms have been in play for a long time, it will take a long time to get the majority of developers to go over to this new technology, even if it has a lot of great features and possibilities that GDI+ does not even come close to.
Visual Studio still have support for WinForms/GDI+ of course, but since Visual Studio 2008 built in support for WPF have been there, and is working just fine.
Silverlight and Flash will never be a mainstream replacement for a native application.
We're a C++ & .NET house, and we use WTL for developing GUI apps for native projects. We don't use GDIplus though, we stick with regular GDI calls.
It is a sticking point, and it's extremely difficult to
Write GUI software using WTL/GDI
Find developers who can do WTL/GDI
Train developers to do WTL/GDI
We're currently evaluating Qt as a replacement for our GUI coding, but at £3k per developer seat, it's an expensive option.
Microsoft recently released tools and documentation for its new Phone 7 platform, which to the dismay of those who have a big C++ codebase (like me) doesn't support native development anymore. Although I've found speculation about this decision being reversed, I doubt it. So I was thinking how viable would be to make this codebase available to Phone 7 by adapting it to compile under C++/CLI. Of course the user interface parts couldn't be ported, but I'm not sure about the rest. Anyone had a similar experience? I'm not talking about code that does heavy low-level stuff - but there's a quite frequent use of templates and smart pointers.
c++/cli can theoretically be used with WPF/Silverlight using the trick of replacing the C# generated from the XAML with a macro definition that can be used inside the main class in a code behind file. I worked out this technique but haven't had the motivation to take it beyond theory - I'm quite happy mixing languages.
As far as using c++/cli in a pure safe mode for your logic code, this may still not be possible but I'd love to hear how someone goes trying it now. Whilst researching it for Silverlight back in 2008 I found this daunting silverlight forum comment:
I just gave Silverlight&C++ it a try by compiling the MSIL from my C++ project into a Silverlight-compatible DLL. The good news: it works, and you can call this code from a Silverlight project. The bad news: The C++ compiler apparently uses MSIL instructions that Silverlight disallows.
So, if you try this, even with the simplest of programs, you'll almost immediately get the exception "Operation could destabilize the runtime." To me, this makes it seem less likely that we'll see Silverlight for C++ soon, as the compiler will need to behave quite a bit differently.
You can generate verifiable managed code in C++/CLI using the /clr:safe option. The problem is that most of your normal c++ code will not compile with that option.
C# is currently the only supported language for WinPhone7.
I fully expect that MS will add support for VB and C++/CLI in the future too, but don't expect to open up the native-code kimono anytime soon.
Native code just has too many issues to overcome, specifically around security, reliability, etc. Managed code is FAR easier to statically verify and FAR easier to control while running.
If you're upset about porting C++ code to C#, just be glad MS didn't force you to have to move to Objective-C ;)
From our own experience, the proces of porting well-written C++ to C# actually takes a lot less effort than one might at first expect. Sure, there's a learning curve, but you have that with any port. We actually got so much benefit from porting our core app and data engines to C# that we re-tooled our entire team to code in C# and port our C# back to C++ where necessary rather than the other way around! So far, we've only ported two modules back to C++ and call our C# code from our native code via interop instead.
Again, remember, WinPhone is a brand new platform using best of breed, highly-productive, next-generation development tools and platforms. It is not your father's WinMo.
If support for C++ is something you find to be crucially important, then make sure MS know - (respectfully and professionally) state your position in the MSDN forums and at developer events near you.
Update1: 2012-12-17:
While native C++ still isn't officially supported for Windows Phone 7, Windows Phone 8 now supports native C++ code so you can more easily port your existing C++ codebase(s) to Windows Phone 8 (as well as Windows 8 and Windows desktop apps).
While there isn't 100% compatibility between the Windows8/Phone8 platforms and API's right now, I expect the two platforms to become increasingly integrated over the next couple of releases.
This is especially true now that one of the key barriers to closer cooperation between Windows and other groups at Microsoft recently left the company ;)
Update2: 4/15/2014:
As per the recent announcements at //BUILD/ 2014, you can now start building "universal" apps in C++ & XAML, C#/VB & XAML or JavaScript & HTML that will run on Windows 8.1, Windows Phone 8.1 and Xbox One! For more details on building Windows Phone 8.1 Universal Apps, read this article.
The whole development idea is built on Silverlight. I think you can add your managed dll written in C++ without any problem to this Silverlight project, but it could not use native code.
I am planning to install the tools on my machine tonight and will try this out.
It is fine if MS decides to leave the path and create something new, that is MS' decision. So let's face the facts. Silverlight is no success yet. MS lost significant share due to Apple, Android and RIM. Application developers simply have to evaluate the business case for their own applications and decide if they trust in a share gain of Windows 7 phone or not. For the company that I run, we decided not to support any more MS Windows phone 7, not because of this or the other technical reason, but just because that we don't believe in the return of our investment for the port.
We start supporting Apple, Symbian, Andoid and MeeGo in the future if we see a market success of this new platform. All support C/C++ and enable us to reuse our proven application cores. So why worry at all. Personal technology preferences should not be gating. If personal preferences worry, then I would kick MS out for their to me ugly looking UI.
Thomas
It is on the horizon finally!
So a survey sent to windows phone developers about their future
development preferences and XNA isn't mentioned once in the Survey (A
survey sent to windows phone developers - did I mention that)
They do however ask:
How would you prefer to use C++ in your mobile apps/games?
Develop apps/games that are C++ from top to bottom (UI, business logic, and platform
APIs)
Use C++ for business logic and then write platform abstraction layer
Use C++ for business logic use 3rd party runtime engines
I don’t want to use C++