Yeah, that’s what we’d use. You think it’s not worth implementing/too low effort? I already checked and FileSystemWatcher is in .NET Standard 2.0.
I am against adding any sort of API for hot swapping on MG side, its easy enough to implement already as is.
IMO “it’s too easy” is not a good argument to leave a feature out. In fact, it’s a good reason to implement it because of the low hurdle. As long as it’s useful that is.
There are multiple ways to implement it and its not platform specific.
I think a better way to put “multiple ways to implement” is “different possible solutions”. For file watchers, if MG provides such a thing, there’s really no reason for people to implement their own version of it. You get notified when assets change, there’s maybe different ways to implement it, but that’s the functionality you want. If you want some extended features you can build on top of that. That’s completely different from e.g. a Tiled implementation, because there’s lots of possibilities for the API and what exactly is supported. If MG implements that one way, some people might not like it and implement their own. IMO that means it’s out of the scope of MG.
I also think that list of requirements should be looked at case-by-case and not used as a hard measure. For example you mentioned font processing/displaying in the GitHub issue: there’s a ton of different ways to render glyphs, but it’s essential to most games, so it makes sense for MG to implement it some way.
Just to add my somewhat-related thoughts to this discussion… I can’t think of another example, but does MG have some way of limiting features to debug builds of a game? I know there’s the DEBUG flag, but that doesn’t get passed through so it would require switching out the debug/release MG binaries, right? Because with a feature like this, I could imagine not only would you not want it running in release mode, but you would probably want to remove it altogether to reduce the assembly size.
If we’d add a class inheriting from ContentManager that simply has an event for when assets it loaded changed, it would be very lightweight. MonoGame currently does not have a system for excluding/including certain features from a build. We could of course do that using custom preprocessor symbols.
XML has attributes, not JSON, so in order to handle the “conversion” to a class, it is not as trivial nor as reliable as you think.
The purpose of hot reloading of xnbs is mainly required by editors, right ? Not in-game ? It would be a nice feature, but I can see many games built with MonoGame, more than editors (2 maybe 3 projects). And as within an editor, when modifying a world object or a shader, the app knows which file has been changed, it is more a thread safe content loading problem at runtime than a FileWatcher on a whole directory (which is not as reliable as it is said)
To be honest, true. It makes more sense to have the IDE take care of changes. I was thinking perhaps it could be a separate MonoGame extension instead to help devs implement the live reloading feature in their engine.
Actually, after working a bit with Audio, I think I’d give that a vote towards a better audio system as I had some issues
A reliable IDE for Linux would be nice. MD 6.2 decided to crash anytime I start a new project.
Haha, that request is completely out of place here 
I vaguely remember that crash being because of the Git integration and i think if you disable the addin it doesn’t happen.
Anyway, there’s VS Code and Rider. I’ve never liked MD myself.
VS Code seemed fine on Linux to me. There was a bit of setup to get the xbuild and nuget restore stuff working, but otherwise no problems.
Yeah, even me stumbled over that git thing. There is no git addon installed. I do have Rider but no idea how to start a Monogame project with it. For now I’m booting Windows and use VSC 2017.
VsCode works like a charm on Linux. I was positively surprised a Microsoft product being so well working on Linux
Yes it does but doesn’t offer a Monogame project. I have no idea how to do this from scratch, I need an IDE for this. I guess, that’s the point of these IDEs.
Geez, I’m fighting with this pipeline thingy. Compile successful and now ? Where are these xnb files and how do I get them into my project…
You would have to copy the templates I think, as VisualCode works with “forders” and not “projects”
Hi there 
I like to mention that the implementation and maintability of one single graphics library is significantly easier as that one of three or four
Vulkan is everywhere and I see less benefits in the others, including old DirectX. To free up human ressources is crucial in nearly all the projects, so consider to focus on one graphics library. 
I guess its possible that I speak to walls 
as often in such obvious cases, while I see a chance which lets you consider this option.
Quality creates Quantity
Vice versa is it impossible
That is not true, Vulkan is only on Windows, Linux, Android, and does not supported older grahpcics cards/devices.You get way more supported devices by using OpenGL.
3 Likes
Well, that includes OpenGL, so far as I am concerned.
I think I read somewhere that they both share large parts of code.
If this is incorrect, I count OpenGL in of course.
They are completely different APIs and have very different approaches to use.
I believe that you will not find Vulkan on iOS or Mac because Apple have their own low-level graphics API called Metal that they support. Apple will not support a competing graphics API.
Vulkan support on Windows, once you hunt down the appropriate drivers, is only supported on recent graphics cards. The same applies for DirectX 12, except for the hunting down of the drivers.
2 Likes