I’m interested in some ballpark estimates (it’s over 31,000 lines of code (plus shaders)), like what kind of OS/gfx components need to be rewritten from scratch, when porting to Mono.
I’m still running on Win7, so XNA runs fine here, but from my understanding that’s not the case with later versions (not sure you can distribute the XNA binaries, probably not and likely they wouldn’t work on recent Win)
Do I have to touch the shaders (ShadowMapping, Blur, Postprocessing, 3D Mesh animation, Terrain normal maps…) ? Being .FX/HLSL, this seems pretty straightforward, hopefully ! We’re talking DX9-category HW here, so that shouldn’t be an issue in 2023.
The game is top-down 3D RPG with camera like in Dungeon Siege. It ran at FullHD on X360 just fine, from what I recall. I also had some codepath for WP7 there (though without shaders, of course).
Since it was accepted to the GreenLight (back in day), I reckon I might finally throw it into the shovelware pile on Steam, given how much effort went into it…
Not yet. I was browsing the forums and it looks like there’s support for VS2022 (just found out).
Right now, I am using VS2017 for porting my old 6-DOF action game from C++/DirectX 8.1 to C++/DX11 (that’s a huge project in itself - ASM shaders vs HLSL, no Vertex Streams, VC6-style I/O, C99, etc…). I had to start with an empty DX11 project and a rotating Cube and only start adding code from there - which I would ideally want to avoid here (if possible) - but then again, DX8.1 → DX11 is a huge paradigm shift compared to XNA->MG
The XNA Game is, however, almost finished and is playable, so I figured I would maybe get that one to market first (depending on effort of porting).
Not sure if VS2017 and VS2022 can happily coexist together (will look into that) as two separate instances.
Hypothetically, I could use VS2022 for C++/DirectX11, but I sincerely doubt the project will just work out of the box after re-opening in VS2022. I’m sure there will be lots of small breaking changes just to get it to compile again (let alone actually work), as has always been the case when switching versions of VS (and being forced to target different libraries/versions). I know I will do the switch to VS2022 once the port to DX11 is done and then I will decide on UWP vs GDK. But that might not even happen this year, so I’d rather not potentially break the current workflow, if at all possible…
Maybe there’s a way to use VS2017 for Mono and just use slightly older binaries/version of MG ?
EDIT: I do know for sure from my last job at MSFT that VS2019 and VS2022 coexisted together, as we were using the VS2022 for the Win10 builds and VS2019 for XBOX builds. I often had them running at the same time. I’ll go install VS2019.
I would certainly gladly spend a week (if only it was that little effort!) and have it running on a supported API!
So, I rolled the dice and installed VS2019. Since it’s not being updated anymore, the risk of it interfering with VS2017 libs is minimal (unlike VS2022 which can break things randomly with any upcoming update).
Since it’s officially not supported, it probably explains why I only found MonoGame.Forms Extension and not the regular MonoGame project templates.
I quickly tried to manually run dotnet new --install MonoGame.Templates.CSharp from the cmd line, but that failed, so I will have to troubleshoot it. There’s few threads around, so I’ll dig deeper first…
Concerning XNA, there are 2 sets of binaries, one for development and one designed for redistribution with your game. There is nothing wrong with bundling the redistributable with your game. I recently installed an XNA 4 game on a Windows machine and it worked fine as long as the redistributables and .net 4 (or maybe it was 4.5) was installed. I suspect Windows 11 would be fine as well.
However, yeah, if you are planning to release probably best to update to the latest version of MonoGame; no one wants to install those old redistributables on their machines. For a 2D game it took me a couple of days to port to MonoGame from XNA 4, although that was several years ago. I can’t speak to 3D and porting shaders as I’ve always been ok with 2D. Most of that was testing, figuring out the new content pipeline tool, and what shared projects were in Visual Studio. I remember some trouble with SpriteFonts that I had to work through. Very little of the source code changed as MonoGame strives to be backward compatible with XNA.
If you are using XNA as intended, it should be fairly straightforward to port, unless there is some difficulties in the 3D / shaders that I’m unaware of.
Best of luck if you go forward with the port to MonoGame,
Brett
Wait, so the XNA 4.0 runtime still runs on Win8/Win10/Win11 ? I didn’t know that was still an option. I recall reading some threads where people had issues on Win10 (which wouldn’t be surprising given the inherent limitations of the original run-time libraries).
I wonder if it’s even legal to redistribute the XNA run-times with your game. That’s usually forbidden, no ?
That being said, I certainly wouldn’t mind spending a week with porting, considering it does give me options of quite few other platforms! Especially given how much effort went into making the game in the first place (around a year full-time given it was initially done in DX8/C++ and only then ported to XNA), though I kinda wrote that off long time ago…
As far as I remember, if you are using XACT for audio there may be some issues, I can’t remember exactly what was the issue a few years ago so I decided to change the audio library, but if you are not using XACT it shouldn’t be a problem.
@MysticRiverGames, I didn’t use XACT, so can’t speak to any issues there. I’m not even sure if MonoGame supports XACT. VladR if you are using XACT, you might want to research what porting that looks like before getting started.
The XNA Framework Redistributable download provides game developers with the XNA Framework run-time libraries they can include with their product for redistribution on the Windows platform.
I’d still update to MonoGame for releasing to public.
I can state that the effort is minimal. Once you have created your new Game from a template and then copy for class files over, there is little to change.
As to Xact, that is not really supported, so you will need to update Audio file use to load the audio files through the ContentPipeline direct rather than using Xact. Unlike XNA, Xact was never open-sourced, so it couldn’t be used really.
The only exceptions are the use of older framework versions like 2 and 3, which do need a fair bit of rework due to the API changes. But 4 and 4.1 are a breeze.