Windows Phone 8, Microsoft's new mobile operating system releasing this fall, will feature Native Code C and C++ support that is designed to make it easier for developers to bring their PC games and apps to Windows Phones.
Microsoft's current mobile OS, Windows Phone 7, has trailed rival smartphone platforms like Android and iOS when it comes to the amount of apps it offers, but this WP8 initiative could entice more developers to release their games to the platform.
This native development platform, which is based on DirectX, enables developers to write the same game for Windows 8 desktops and Windows Phone 8. This will be possible because the same DirectX components and graphics support on PCs will be available on Windows Phones.
During a presentation for the platform on Wednesday morning, Microsoft showed how developers could also take their games created for other mobile platforms, and port them to Windows Phone 8 in as little as two weeks thanks to Native Code support.
"A game developer who authors a detailed rich immersive compelling experience for PC, has a super easy port of their game to phone," said Windows Phone corporate vice president Joe Belfiore at the presentation. He predicted that visually impressive titles would begin appearing on the platform before the end of the year.
Microsoft announced a number of middleware partners that will offer support for Windows Phone 8 in their technology and tools: Havok, Audiokinetic, FMOD, and Autodesk.
The company revealed a couple of game publishers who've already signed up to bring games to Windows Phone 8, too: Gameloft (Asphalt 7: Heat, N.O.V.A. 3) and Big Fish (Fairway Solitaire).
Zynga will also bring its popular iOS and Android titles to the platform for the first time later this year, with Draw Something and Words With Friends.
For me personally C and C++ native code support isn't a concern as I like C# but I can understand how others use those languages and that is a bonus for them.
You may have to change your thinking soon. The future of XNA is uncertain. There's no word on an update AFAIK, so XNA will be supported on Windows 8 only by using backwards compatibility, even then it doesn't run on ARM processors, that means no XNA on tablets. Beside that, there's nothing certain whether the framework will be supported at all on the new Xbox, even now it's not like XNA games are fully supported by the 360, they run in a sandbox for security reasons.
Naturaly there are other options for C#, but still.
I've considered unity but to release on a mobile platforms I'd need to buy a license and as it stands I can't afford said license and will stick with XNA for now but in the long run obviously I will have to get used to other tools and APIs.
Even if you like C#, a lack of native support created a wall.
Major mobile engines didn't even have the option of working with Windows Phones, unless they completely rewrote the entire engine in managed .NET, including 3rd party libraries they relied on.
This means that a whole gamut of engines and libraries will be able to be used in Windows Phones games. And it also opens up the options to use the language of your choice, rather than being restricted to what they provide, allowing you to use the tools you know, and whatever fits your project best.
@Slade: Programming farther away from the hardware isn't always terrible providing the interfaces to it are good. Productivity goes up in general because code is easier to write and bugs go down because the environment is safer by nature.
The performance impacts are not that huge when you can factor in the productivity gains. Developers are as significant a resource to consume as clock cycles.
@Slade: How do you mean? Developer time is a clear resource provided you are paying them a salary. In most cases it's the most important resource to manage correctly.
@Slade: "I treat programmers like cosmonauts instead."
Knowing the history of the early USSR space program, I can only assume you mean something else by this statement (or you really dislike programmer ;)).
I'm with Michael on this one. If pushing the performance of the machine isn't an issue than it is better to use a managed language like C# because the programmers can spend more time actually creating something, and less time making sure the code works.
@Slade: Time is a consumable resource. You have consumed some of it writing your posts rather than programming. I am consuming some right now. Time is the epitome of a non-renewable resource.
"but, I don't think you know what it *feels* like to be a programmer. "creating something" and "making sure the code works" are not mutually exclusive thoughts, for any programmer worth her salt."
They aren't mutually exclusive, but they are not the same either. There is a large subset of "making sure the code works," that's just a language tax. It isn't any contribution to the creativity of the project, and it isn't anything that will be noticed by the customer. It is just lost time by virtue of choosing a certain language. It's true for all languages, even managed ones. The only difference is how large that tax is; generally the closer you get to hardware the larger that tax becomes.
What about the business side of app dev for Win8? I recall with my previous company having an easier time getting on iOS than XBLIG. I mean I know it's microsoft, but on can hope for a more streamlined, open platform right? I mean essentially a WinPC is the most open platform out there, you just make a game and sell it. (Not to mention it's delivered/played on the same type of device it's made on). My hope is that MS can find that happy middle-ground for new platforms that iOS did. Android is so open that it's hard to make expenses and Nintendo's current platforms represent the other end of the spectrum. Nintendo makes it more difficult than IMO it should be to release on their consoles.
Seems pretty silly to say that it's an "easy" port. The code compatibility side of things has never been a big deal creating an android or iphone game. The difficulty is always in specific screen sizes as well as user interface (eg touch screen). Oh and also power of the device. I'm fairly sure a high end pc game will not run well on a mobile device.
Having C++ is good, but a number of libraries are missing:
* Replacing OpenGL with DirectX is not something that will take 30mins
* OpenAL is also missing, as are pthread and other posix libs used on iOS/Android
Naturaly there are other options for C#, but still.
Major mobile engines didn't even have the option of working with Windows Phones, unless they completely rewrote the entire engine in managed .NET, including 3rd party libraries they relied on.
This means that a whole gamut of engines and libraries will be able to be used in Windows Phones games. And it also opens up the options to use the language of your choice, rather than being restricted to what they provide, allowing you to use the tools you know, and whatever fits your project best.
The performance impacts are not that huge when you can factor in the productivity gains. Developers are as significant a resource to consume as clock cycles.
Knowing the history of the early USSR space program, I can only assume you mean something else by this statement (or you really dislike programmer ;)).
"but, I don't think you know what it *feels* like to be a programmer. "creating something" and "making sure the code works" are not mutually exclusive thoughts, for any programmer worth her salt."
They aren't mutually exclusive, but they are not the same either. There is a large subset of "making sure the code works," that's just a language tax. It isn't any contribution to the creativity of the project, and it isn't anything that will be noticed by the customer. It is just lost time by virtue of choosing a certain language. It's true for all languages, even managed ones. The only difference is how large that tax is; generally the closer you get to hardware the larger that tax becomes.
* Replacing OpenGL with DirectX is not something that will take 30mins
* OpenAL is also missing, as are pthread and other posix libs used on iOS/Android