We wrote a game on XNA Game Studio, starting in 2012, and now want to upgrade it to MonoGame. XNA is still tied to Visual Studio 2010 edition, and is generally outdated and non-supported.
Is there a manual somewhere or web page that describes the general porting process? I would imagine that this might be a fairly easy upgrade.
This game has a game Editor built on Windows.Forms, which would be nice to keep around (at least for the start). Xamarin.Forms sucks bad, but WPF is likely an acceptable solution, if needed. Windows.Forms are so easy to use with the IDE and all. While Xamarin.Forms makes me feel like I’ve just gotten in a time machine and rewound to the 1990’s, doing text-editing to try and make a layout. (yeeesh!)
If it is XNA4.0, then porting should be without too much trouble. Create mg project (with netcore , copy your files to that project and then compile ). There is at least one method which isnt xna api anymore so need to remove some parameters. If you want to 1:1 xna, then you should test FNA. I have only a few #ifdef in my code which compiles with MG,FNA, and MG-web.
Forms, there is this project (I have not tested this so cannot say is this similar than Windows.Forms which I used years ago when I did a little game editor
I had a project that I was leaving in VS2010 because of the tie to XNA 4.0. Technically, you COULD use XNA 4.0 in some later versions by fiddling with some setting, but I never tried that…partly because VS2012 was ugly, VS2013 wasn’t great, and so on, but VS2019 is really nice, so I felt I ought to move over to MG 3.8.
The project was WinForms using Framework (not Core), with XNA drawing certain controls on a form. The steps I had to do was essentially this:
Open the VS2010 project in VS2019.
Add MG 3.8.
Remove the XNA references.
Build.
Ask questions here.
Basically, it mostly worked fine with no particular changes. There WERE a few changes, though, and they appear to be due to MG3.8 being based off DirectX11, whereas XNA 4.0 was based off DirectX 9. There are some slight difference in how those worked, so a few pieces of code that I had for drawing controls had to change. This was due to a change in the way render targets worked, as far as I can tell, and whether or not it will impact you depends on how you are doing things currently.
I also found that there was a difference in the way a bit mask stencil had to be set up. Essentially, you can look for threads I started and see what issues I had. It’s only been a couple months, so you wouldn’t be looking back very far. You’d quickly realize that I had very few issues, and you should take one particular lesson from this: Though it could have been difficult…it wasn’t.
I never used a content project. I just had a few resources that I loaded.
In my case, I was working on a plugin system with a bunch of dynamically loaded dlls. There were few resources, but those resources were spread between the main project (a bunch of graphic items) and the plugins (a few other graphics and effect items). In general, there were VERY few graphical resources compared to most any game, due to the nature of the project, and the fact that some were common while a few were specific to plugins, meant that I never got around to a content project.
Wow, that was easier than I thought. The way I did it was to hand-edit the Visual Studio project files to match that of the MonoGame.Samples projects. And it “just worked”. The only trick was with the Content project, which uses the new MGCB file extension, and the MGCB Editor, and such. I still haven’t worked out the kinks there, but was able to port it “as is” to MonoGame.
Now it’s running fine, except for some visual bugs, and the XNA Input is misbehaving for me.
My whole game runs inside of a GameControl which is a child of our GameEditor window (so it’s just a panel of the whole window). And between native WinForms and the new WinForms for .NET Core 3.1, there are differences in how XNA Input seems to gain/lose focus.