6 ms·

Monogame isn't really an engine, more of a framework, but its API is so static that you can copy/paste 11-year-old code in XNA 4 Framework tutorials into your M

Monogame isn't really an engine, more of a framework, but its API is so static that you can copy/paste 11-year-old code in XNA 4 Framework tutorials into your Monogame project and it will probably just work (shaders, storage, and a few other things are different). I did that just yesterday. (Monogame was initially created to match XNA 4 API). I didn't even try porting my 10 year old XNA game until a year and a half ago, and I was able to get it compiled and running with 90% functionality (again shaders and storage was broken) in just 24 hours. And they just had a major new release that, among other things, supports .Net Core, just two months ago, yet I'm still able to do this.

BoorishBears 6y ago
Apples to oranges would be the understatement of the century here... Monogame is _literally_ an implementation of XNA 4: https://www.monogame.net/about/ https://www.monogame.net/about/ > MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. It's raison d'etre is to let you run stuff that ran on XNA 4 specifically, you could almost say it's psuedo-ABI is XNA 4. So while they've built on that... it shouldn't be surprising that yes, literally the one thing it was built to do, works. I mean it's to the point once upon a time XNA's API reference was MonoGame's documentation and to this day they match, even if it takes harming the soundness of the API: https://gamedev.stackexchange.com/questions/67040/where-is-monogames-api-reference https://gamedev.stackexchange.com/questions/67040/where-is-m... https://github.com/MonoGame/MonoGame/issues/5487 https://github.com/MonoGame/MonoGame/issues/5487 - Also you realize XNA broke stuff on it's major releases too right? It's actually kind of ironic and funny you'd bring up XNA 4, because it REALLY broke stuff: https://www.shawnhargreaves.com/blog/breaking-changes-in-xna-game-studio-4-0.html https://www.shawnhargreaves.com/blog/breaking-changes-in-xna... Literally the words of a Microsoft dev lead at the time: > I was relieved when the comments on my earlier post about backward compatibility agreed with the approach we chose for XNA Game Studio 4.0. Banjobeni summed up the general sentiment: > "If you break it, break it good." - But also, and I mean you allude to this right there in the first sentence, it doesn't have half the surface area Unity has, it'd be like pointing out SDL's API staying stable? Even if you look at something that isn't Monogame I'm sure you'll find some frameworks that have had static APIs for decades, after all, if your layer of abstraction is high enough while your scope is small enough, DrawPixel 0,0 is still probably going to end up drawing a pixel somewhere just like "forward 50" is going to "move the turtle forward 50"... But then to that point, the basic APIs like that in Unity haven't been completely ripped out or something, they're still there in the same way they were. I googled "how to jump unity" with older than 2007 and this code still works 7 years later: https://answers.unity.com/questions/30127/how-can-i-make-my-character-jump.html https://answers.unity.com/questions/30127/how-can-i-make-my-... Sure Unity added a new Input system, but they don't force it on you, it's not even enabled in new projects by default (probably so you can cut and paste 13 year old code and have it work) Even Unityscript, the most glaring removal since Unity 1, has an official conversion tool, and deprecation wasn't even started until heavy usage had dropped to under 4%. I actually find it a great example of how to deprecate software gracefully. They waited for usage to fall off, they had excellent reasons to drop it, and they bent over backwards to make it painless. If you're just doing basic stuff like moving CharacterControllers around and stuff decade old code still works in Unity. Most basic tutorials from back in the day still work. What broke was fancy shaders that were written back when graphics models we use today weren't even an academic concern... and like you pointed out, that's stuff that breaks as time moves on because it's just not high-level enough to be easy to have work in a backwards compatible manner

BoorishBears 6y ago

Apples to oranges would be the understatement of the century here... Monogame is _literally_ an implementation of XNA 4: https://www.monogame.net/about/ https://www.monogame.net/about/ > MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. It's raison d'etre is to let you run stuff that ran on XNA 4 specifically, you could almost say it's psuedo-ABI is XNA 4. So while they've built on that... it shouldn't be surprising that yes, literally the one thing it was built to do, works. I mean it's to the point once upon a time XNA's API reference was MonoGame's documentation and to this day they match, even if it takes harming the soundness of the API: https://gamedev.stackexchange.com/questions/67040/where-is-monogames-api-reference https://gamedev.stackexchange.com/questions/67040/where-is-m... https://github.com/MonoGame/MonoGame/issues/5487 https://github.com/MonoGame/MonoGame/issues/5487 - Also you realize XNA broke stuff on it's major releases too right? It's actually kind of ironic and funny you'd bring up XNA 4, because it REALLY broke stuff: https://www.shawnhargreaves.com/blog/breaking-changes-in-xna-game-studio-4-0.html https://www.shawnhargreaves.com/blog/breaking-changes-in-xna... Literally the words of a Microsoft dev lead at the time: > I was relieved when the comments on my earlier post about backward compatibility agreed with the approach we chose for XNA Game Studio 4.0. Banjobeni summed up the general sentiment: > "If you break it, break it good." - But also, and I mean you allude to this right there in the first sentence, it doesn't have half the surface area Unity has, it'd be like pointing out SDL's API staying stable? Even if you look at something that isn't Monogame I'm sure you'll find some frameworks that have had static APIs for decades, after all, if your layer of abstraction is high enough while your scope is small enough, DrawPixel 0,0 is still probably going to end up drawing a pixel somewhere just like "forward 50" is going to "move the turtle forward 50"... But then to that point, the basic APIs like that in Unity haven't been completely ripped out or something, they're still there in the same way they were. I googled "how to jump unity" with older than 2007 and this code still works 7 years later: https://answers.unity.com/questions/30127/how-can-i-make-my-character-jump.html https://answers.unity.com/questions/30127/how-can-i-make-my-... Sure Unity added a new Input system, but they don't force it on you, it's not even enabled in new projects by default (probably so you can cut and paste 13 year old code and have it work) Even Unityscript, the most glaring removal since Unity 1, has an official conversion tool, and deprecation wasn't even started until heavy usage had dropped to under 4%. I actually find it a great example of how to deprecate software gracefully. They waited for usage to fall off, they had excellent reasons to drop it, and they bent over backwards to make it painless. If you're just doing basic stuff like moving CharacterControllers around and stuff decade old code still works in Unity. Most basic tutorials from back in the day still work. What broke was fancy shaders that were written back when graphics models we use today weren't even an academic concern... and like you pointed out, that's stuff that breaks as time moves on because it's just not high-level enough to be easy to have work in a backwards compatible manner