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.
Related
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
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 have an iPhone, an Ipad, don't have yet windows phone 7, but will get it right now if rebol can run on windows phone 7 so does/will rebol support it :)
Note: rebol could run on windows mobile so my question : will it continue to run on next version ?
Well if they don't release NDK, I will buy a tablet with classic Windows 7, that for sure can run rebol and a bunch of softwares I already have :)
When the ARM core library will be compiled, it may be possible for someone to port the host-kit to many new hand-held devices including Windows Phone 7, Android and even the iPhone (since they relaxed their TOS).
The ARM library is already high on the wish list of many people who are willing and able to work on the host-kit part of REBOL 3.
With 5 host-kit platforms already maintained by different developers (some indie) already at different levels of completion, the answer is not IF but rather WHEN will R3 run on these new exciting devices.
IMHO R3 still needs a little more stability work for mass porting, but in the last 2 months, I think R3 has matured to levels that are starting to catch up to R2 in many areas.
One good thing is that the extension API is proving to be highly effective and fast. Its design is also stabilizing which is a good sign of the current maturity of the host-kit.
A caveat
One must understand that many mobile platforms have strict development licenses and some even have hard to integrate APIs into which executables must try and link in.
Many don't even want binaries to work directly and the road to integration isn't meant to be easy on purpose. AFAIK winphone7 is probably the easiest one of the bunch, so don't despair.
Not until Microsoft or a third party releases a "native development kit" (NDK). The same problem hampers others, such as Firefox, who cannot readily port their apps to Silverlight, XNA or the .NET CF (which are the only Microsoft-supported development platforms at the moment).
According from Emulator Color Depth on Windows Phone 7 forum, I just heard about limitation of Silverlight on Windows Phone 7 that it display only 16-bit color-depth image on Silverlight application just like previous version of Windows Mobile.
Is it true? Anyone can confirm this.
PS.Normally, Silverlight natively support 32-bit color-depth and all modern smart phones also support 24-bit color-depth. I'm not sure what color-depth will be displayed. I have quite bad experience for using HTC Sense in windows mobile 6.5 on my Omnia Pro 2(OLED display with 24-bit color-depth support).
Thanks,
It's been suggested that the minimum spec for devices is 16 bpp, however I haven't seen the documentation for this despite looking for it. OEMs are free to go beyond this... arguably it will be up to them to put their best foot forward.
There was more background to that discussion you linked in other threads, including the one below. The one you linked doesn't offer a lot of context.
Emulator gradient quality different from Blend
I think the thing to do at this point will be to look at what's being done on specific devices.
As yet, hardware spec tables I've seen aren't documenting this detail, but it would be good to see.
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++