I have mobile phone game cores - by this I mean the pure game logic - (framework independent, i.e. gfx rendering, data loading, user input, sound/music playing is separated), written either in C or C++ language – the code was running in the past on the Symbian, Windows Mobile 5.x 6.x and Maemo (now MeeGo) . I was thinking of porting some of those games to Windows Phone 7 using the XNA. My question is – do I need to rewrite the core in C# or I can compile to MSIL and use as a DLLs?
Added later:
Check this:
Windows Phone 7 and native C++/CLI
There is no C/C++ compiler for Phone 7. There isn't one for any version of the Compact Framework, in fact, and any "workaround" is likely to generate IL opcodes that are unsupported by the CF.
What this mean, in practicality, is that C/C++ is unusable for anyone working on Phone 7 (except the phone OEMs themselves) and your code will have to be ported to C#.
Port the games to XNA. Don't port the game engine to .NET, since Windows Phone already have a game engine called XNA.
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.
I have a decade old MFC VC++ desktop application. Beauty of the application is it works from Windows 2000 to Windows 7, in more than 15 languages. Its multithreaded with IPC and SSL on top of winsocket.
Lately i am reading that win Windows 8 Metro style we will not be able to run the existing application. Does that mean Windows is heading towards killing VC++ or MFC?
Is there a possibility of me keeping same code base for all windows versions? Do I have alternative APIs for winsock and MFC? Is it compulsory to write the app in HTML5?
Lately i am reading that win Windows 8 Metro style we will not be able
to run the existing application
I find it easier to think about things in terms of the Windows Runtime (WinRT). The ARM based Windows 8 systems will only support WinRT programs. The x86 based Windows 8 systems are capable of running both WinRT programs and existing Win32 programs.
There is an implication (or possibly an assumption?) that all Metro style applications are WinRT applications. Certainly WinRT is intended for use in building Metro style applications. I could imagine building traditional Win32 applications that looked like Metro apps - big square active tiles, an application surface that stretched to the left and right of the visible desktop etc. I'm not sure those would really be considered "Metro style" apps even if they were built in the same style as a Metro app.
Existing applications will not run on ARM based Windows 8 systems and will not run in the non-Desktop part of the x86 based Windows 8 systems. They will run in the desktop part of the x86 based Windows system. That's where Visual Studio runs, that's where PhotoShop will probably run, that's where all the programs that currently run on Windows 7 will run.
Does that mean Windows is heading towards killing VC++ or MFC?
Absolutely not. MFC applications will run just fine in the desktop environment of Windows 8 on x86 based systems. MFC applications will not run on ARM based Windows 8 systems - but then there are lots of places MFC applications won't run.
As for VC++, you can build Metro style applications using C++ if you want to, you just have to follow the Metro "style".
Is there a possibility of me keeping same code base for all windows
versions?
It depends on what you mean by "all windows versions". The code that runs on Windows 7 x86 based systems today will run on Windows 8 x86 based systems tomorrow. If that's your target market then you're done, you don't need to change your code. The only thing you won't have is an active tile. But you could build an active tile using the Metro style APIs and tie that back into your app's logic if that makes sense.
If you want to support ARM based Windows 8 systems as well as x86 based systems, or if you want all of your program to have the Metro look and feel when running on x86 based systems then you'll have to change your program to use HTML/CSS or XAML and the WinRT APIs instead of MFC and the Win32 APIs.
Or if you want both worlds, perhaps you might even seperate your program's logic from the UI and then build an MFC skin and a Metro skin around that common logic
Do I have alternative APIs for winsock and MFC?
For networking there are a number of classes you can use from JavaScript, Visual Basic, C# and C++. For building UI you either use HTML/CSS or you use XAML.
Or you continue to use MFC if that fits your needs. You're probably never going to ever build a Metro style app that's got a Multiple Document Interface with a Tabbed UI!
Metro Style is all about user experience and different UI layout. If you want to utilize metro style UI in your app then you many need to write a WinRT wrapper around you app to utilize it. That doesnt mean that your application will not run at all in Windows 8, all the leagacy application still run in Windows 8
Are there any game engines available for a Windows 8 metro style application?
There are several game frameworks you can use to develop Metro Style games:
C++/DirectX:
CoCos2D http://cocos2d-x.org/news/54
C#
MonoGame which is great if you have an XNA code base, http://monogame.codeplex.com/ And as stated above SharpDX is a C# framework that wraps DirectX. MonoGame also uses SharpDX
HTML5:
EaselJS - http://www.createjs.com/#!/EaselJS
ImpactJS - http://impactjs.com/
Standalone Editors:
Construct 2 is another tool that supports Windows 8, compiling down to HTML5 - http://www.scirra.com/tutorials/272/how-to-make-a-windows-8-metro-app/page-1.
GameSalad now has support as well - http://gamesalad.com/creator/windows-8
I don't believe any proper game engines have been ported to win8 yet (as of this writing) ... so you will currently need to write directly to the DirectX libraries.
If you use C#, take a look at SharpDX: http://code.google.com/p/sharpdx/
Another two cents:
Delta Engine http://deltaengine.net/
Ogre Engine http://www.ogre3d.org/
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
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++