Porting to MonoGame

[hifi]

I spent this morning furiously hacking UltimaXNA until I got this on Linux on Mono and MonoGame:

Would it be an interesting goal to make UltimaXNA portable to non-Microsoft platforms with MonoGame? Mostly my problems were with the abysmal amount of PInvoke and I didn't even debug why the colors were that off.

[SaschaKP]

That's truly interesting, since it can at least compile and work.

Anyway, I think this has to be finished before starting a port, there are still many parts that need a workout.

[hifi]

MonoGame is essentially an open source version of XNA with most of the API in place. Getting this on MonoGame makes it easier for people to contribute when they can work on the project on other platforms than Windows.

I can't contribute anything unless it runs on Linux, for example.

[SaschaKP]

well, then I'm in with you, I think that effectively this can get lot of support from the *nix community.

If I were you, I would look into UOFiddler and ultima.dll, it's written in c#, so you can extract code from there. It renders all gumps and images correctly, and I can guess that's a problem in rendering or maybe reading the files.

[hifi]

There's no point in doing it unless the project maintainer(s) agree. The port can be done and I think it's relatively easy but it's not worth anyone's time unless it's a mutually agreed goal. I'm not interested in forking and leaving more dead code behind so need to wait for for an official response.

[fdsprod]

The official response is that @ZaneDubya wanted to get it finished in XNA for Windows before looking into porting the code.

[orsi]

I'm sure @ZaneDubya would love a Linux port eventually. Doesn't hurt to fork and experiment on it yourself in the meantime though.

[cmileto]

wish there was a linux port. Im not installing windows just to mess with xna

On Sun, Oct 16, 2016 at 6:10 PM, Jeff Boulanger notifications@github.com wrote:

Closed #432 https://github.com/ZaneDubya/UltimaXNA/issues/432.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ZaneDubya/UltimaXNA/issues/432#event-825238932, or mute the thread https://github.com/notifications/unsubscribe-auth/ADAs46IadC-T61d0A1RlvjM_dYLvwkh7ks5q0qDGgaJpZM4KX5p1 .

[hifi]

I spent a few more hours and I got it to a state I could login to a local shard so given enough time it would definitely be playable but I'm not going to spend more of my time on something that's not going to be merged in.

For a project this scale, I don't have much hope for it to be "finished" before letting more developers in. The number of XNA Windows developers that also love UO is very limited.

Thanks for the quick response, though.

[fdsprod]

@hifi I would say the number of capable developers who love UO is getting limited :(

[hifi]

@jeffboulanger Using a platform only a handful of open source developers want to touch doesn't really help your cause. Just sayin'.

[orsi]

@hifi Make a linux based UO client and we'll be glad to send some pull requests your way.

[hifi]

@jorsi Why would anyone make a Linux only UO client? That doesn't make sense at all.

[fdsprod]

@hifi So let me give you some background on this project. @ZaneDubya started this project many years ago. It was a solo project to help him learn how to write a game, and to recreate a game he loved playing in prior years. Over the course of the years it has continued to only be a hobby project that he works on from time to time, when he gets an itch to code and has free time. Without getting into to much detail about his personal life, he is not a professional coder, and have very little time for hobby'ing right now, so this project has been for lack of a better term, stale, for a few months now. He is the only person actively working on it. I myself have contributed a fair bit, but between life work and my general lack of interest in UO, I've stopped contributing code and only help maintain in areas of questions (such as these) and community efforts.

This project was started on XNA and will be finished on XNA, thus stated by from @ZaneDubya. He has repeatedly said this, and his reasoning is because he doesnt want to have to support multiple platforms, because again, he has no time for that. Since he is the only one currently working on this, there is no reason to change that opinion.

You however are 100% free to fork the code, and continue the project on another platform as you see fit. In doing this you assume the responsibility of figuring things out on your own, and providing help to those that use your fork in lieu of this one. You have however stated something on this matter, and I would say you are right, it would likely turn into just another dead fork of this project, or like many other UO client replicas found on the internet... lack of interest, time, or dedication (or all of the above). It truely takes a very very very long time to develop something like this, and to many people fail to see this before venturing on the path.

Given everything I've stated above, I wish you the best in whatever decision you take, and I'm sorry this project doesn't fullfill your needs at this time. Hopefully, if its ever finished, and @ZaneDubya has time and interest in porting it, that happens. But until then, the wishes of the author are that it stays in XNA and continues to be developed for 1 platform (unless you want to fork it obviously).

[hifi]

I still get the kind of vibe from the comments that people don't really understand what MonoGame is and that it would require a complete overhaul of the client to get it to work and it's not the case. MonoGame isn't a completely different framework, it's a cross-platform replacement for XNA and has 90% of the same API available and works as a drop-in for almost all non-Windows specific code.

I find it odd that the original author sees it being a "support nightmare" when the project isn't even finished and if he doesn't really have time to work on the project it would make even more sense to let more developers in by relaxing the strict Windows and not cross-platform XNA requirement.

For a fork to happen there would need to be more people involved in the process as I'm not an expert when it comes to rendering accelerated graphics or audio for that matter so I couldn't even make it work well on my own.

It's a shame a project that has a lot of potential is in this state. From some of the comments it seems there would be more interested parties to contribute but can't because of this.

[fdsprod]

If that many ppl are interested then fork it, I'm done commenting on this matter, good luck.

[orsi]

@hifi You are interested in porting this to linux, so apparently you want to make a linux-based client. It's not that no one here will support you, which I think is the contention, but that the available support for the original goal -- Windows, XNA framework, one version UO client -- is rather limited already. You can see the commit history and see that development comes in spurts, and from very few authors who are probably either wanting to learn a few things (e.g. me), or looking to help out in whatever interests them.

In all honesty, if it were to come to the point where you forked the project and made it work with MonoGame, @ZaneDubya would probably evaluate and consider extending the goals of the project. He's a very nice and kind man, but he also has a separate life that is far removed from developing even his own UO client right now.

[frozenblit]

Are the currently missing features from UltimaXNA necessarily platform-specific? A proper abstraction could ensure that Zane doesn't have to worry about them. I'm not familiar with XNA nor MonoGame, but wouldn't it be possible to refactor and isolate the platform-specific bits into few classes? A fork as a proof-of-concept would be great, and probably convince Zane that it's worth merging it back.

Also, the possible benefit of more eyeballs should not be disregarded so soon.

Just my two cents...

On Mon, Oct 17, 2016 at 5:12 PM, Jonathon Orsi notifications@github.com wrote:

@hifi https://github.com/hifi You are interested in porting this to linux, so apparently you want to make a linux-based client. It's not that no one here will support you, which I think is the contention, but that the available support for the original goal -- Windows, XNA framework, one version UO client -- is rather limited already. You can see the commit history and see that development comes in spurts, and from very few authors who are probably either wanting to learn a few things (e.g. me), or looking to help out in whatever interests them.

In all honesty, if it were to come to the point where you forked the project and made it work with MonoGame, @ZaneDubya https://github.com/ZaneDubya would probably evaluate and consider extending the goals of the project.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ZaneDubya/UltimaXNA/issues/432#issuecomment-254236507, or mute the thread https://github.com/notifications/unsubscribe-auth/ABnRMkTEeZD1_3oAvuBAjsTlBDdhBK0_ks5q05BFgaJpZM4KX5p1 .

[PatrikSamuelTauchim]

Monogame was already mentioned in #28 in 2015 and there also is @ZaneDubya response on that.

There are probably no doubts that Monogame is a future of XNA games, since XNA is dead.

I dont really think, that Linux (2% penetration) and Mac (+-10?% penetration) is now a major concern for UltimaXNA development. However it can became necessary to move to Monogame, if we hit some XNA limitations (except for single platform), that Monogame doesnt have.

As @jorsi said, lot of work done on this project was from few people that wanted to use client for themselfs, were missing some feature and they were able to implement it. Or just fixed some bug that were annoying to them.

Good thing on linux community is fact, that there is lot of programers and developers, but they are not interested in coding for Windows project, but COULD BE interested in Monogame fork.

What I would recommend is to create fork, get it working at 100% at Monogame, keep it up with XNA version for some time and get some more developers for Monogame, than for XNA. With working Monogame fork and active development it will be very easy, for rest of XNA developers, to move to Monogame.

It is goal for all of us to have this "done" and I think that nobody really cares if is XNA or Monogame.

[muratsu]

AFAIK, UltimaXNA is based on OpenUO. I've forked OpenUO and ported over Monogame 3-4 years ago. If you're interested you can check it out: https://github.com/muratsu/open-uo The required changes are minimal since Monogame is pretty much a drop-in replacement of XNA.

For windows folks, one advantage of using Monogame would be that the project can move to a newer version of VS IDE. Since xna is abandoned, it won't work on newer VS editors and I'm not a huge fan of installing vs2k13 and newer versions side by side.

[fdsprod]

It's not based on open up, more just the original ultimate sdk.

[fdsprod]

It's not based on open uo, more just the original ultimate sdk. I tried to get Zane to build it on open up but he wasn't interested at the time

[muratsu]

Ah thanks for the clarification @jeffboulanger. I'm not really familiar with the codebase of UltimaXNA - in that case engine replacement might be not as easy.

[hifi]

I would probably start a fork by having UltimaXNA as a git subtree and create a new solution/csproj that uses the code from within the subtree and replacing the classes that aren't portable with portable ones. That's basically what I did do but in more hackish way. That also preseves UltimaXNA and it's fairly easy to get updates from the main project.

Also this seems to be the most active issue in 2016 and in under 24 hours. Maybe there is hope.

[muratsu]

I would suggest switching the engine on Windows first and fix the x-platform bits after. Smaller patches are easier to work with.

[hifi]

@muratsu That is true, but that would require Windows. If someone could start by doing that first and I could attack the Mono/Linux issue, that would be splendid.

[orsi]

I might try my luck at it, since I am developing in C# at work now. Not promising anything though, I'm rather uninformed when it comes to XNA/MonoGame overall and this seems like it might be over my head.

If it sparks some new blood in the project it'll be worthwhile.

[SaschaKP]

I'll follow, and I have windows, so I have just to use Monogame and see how it works in windows?

@hifi I need to know what are the changes you made to make the code at least compile.

[hifi]

@uoitalia Since there's interest, I'll clean up my hacks into the format I described earlier to make it buildable and remotely runnable on MonoGame. You probably only need half of them on Windows but they will be cleanly separated from UltimaXNA so it should be easy to cherry pick what you need. Will try to do it tonight.

[hifi]

@uoitalia https://github.com/hifi/UltimaMono here you go, that's the minimum changes required for it to build on MonoGame (main executable).

For issues regarding the port, we should move the discussion to that repo. I'll add some gotchas as issues.

[ZaneDubya]

@jeffboulanger Thanks for keeping people informed! Everything you said is correct.

@hifi This looks like an interesting effort.

With regards to the color issues - have you tried exchanging the values of the R and B channels?

With regards to the shader issues - you'll likely have to build the content with a MGContent solution, and you'll need to build for a slightly different PS model on Mac and Windows (Linux may be able to use one or the other or both of these). I've done some work with MG before, and in my experience, building content was not as straightforward as the automatic builds that you get with XNA if you want to have shaders that work for multiple platforms. I believe you'll need to build the shaders and then include then as binary files. Given that shaders change only infrequently, this likely won't be an issue.

I want to ask you for your opinion on severing the upstream link. My opinion is that if you fork instead of creating a new repo, it will be easier to merge the code you add to this repo, and to merge any changes I make back to yours. Manual merging can be a pain. That said, if you would prefer not to maintain the link back to my master, I do not have any problems with that personally (and you're correct in noting that there's very little activity on this end, so it may be an academic argument). I'm only thinking of ease of merging from both ends.

You quoted me in this comment but I do not remember using those words and my google-fu isn't turning up any references. Can you refresh my memory as to where I said that, or change the quote to reflect what I've said in the past? It may be that this is a non-issue, but I don't want anyone to get the wrong impression of me. I try to be very circumspect in my statements, and I'd like the record to reflect that.

Good luck with your effort!

[hifi]

@ZaneDubya I quoted @jeffboulanger when he said you don't want to "support multiple platforms", it wasn't an exact quote from you and it might have been exaggerated so there's for the record. I didn't really like the approach of @jeffboulanger talking on behalf (even if it's agreed upon) and it made me more annoyed than I should have been.

I did build the shader as seen here https://github.com/hifi/UltimaMono/issues/1 and I have no idea if it works or not as the world isn't really rendered at all at this point. Regarding colors, the actual textures have the wrong colors as well when saved as PNG. Now that I have cleaned things up I'll get back to that point again soon and dig it further.

Regarding the repo, the upstream hasn't been severed. Your repo is a subtree and it can be committed to and merged back from within UltimaMono. I wanted to keep them completely separate for various reasons:

• Many cross-platform bits are are "rewrite this whole class" making the diff useless anyway
• Merging only parts of UltimaMono will be a manual task anyway as the history will be ugly
• Upstream commits that most likely do not have any platform code changes can be pulled in without merging
• Testing can happen side-by-side by selecting what to compile (UltimaXNA class or UltimaMono class) as they are joined together

If changes from UltimaMono are upstreamed, the modified classes can simply be removed from UltimaMono and after pulling the latest changes from UltimaXNA the build just needs to be changed to use the original class instead. I'm not sure if this is the absolute best approach but I've always wanted to have a valid use for git subtrees so there you go.

Some bits that can be upstreamed without breaking XNA would be simplified non-native input handling and such if you're up to merging that kind of things. Although there are problems with that as well as there doesn't seem to be a notion of actual typed characters in the standard MonoGame/XNA keyboard input stuff. It could be that a portable version of the input system needs to be separated in-tree by a runtime check to have more rich input on Windows.

The burning question is: if done correctly and finished up, would you merge everything back in to make UltimaXNA fully portable on MonoGame?

[ZaneDubya]

@jeffboulanger and I are equally qualified to speak on behalf of this project.

Thanks for responding to my questions. I don't want to promise to merge the MG solution back in before seeing the final code. I hope you understand.

I would not merge it absent feature parity across the mac, linux, and windows platforms. I don't want to support people asking why a given feature did not work on their platform.

I don't have the time or knowledge to help you troubleshoot your MG efforts. For that reason, I'm going to lock this thread. But I wish you luck! Please open a new issue (or PR, if that's possible) on this repo when you're ready to push your changes.

[fdsprod]

@hifi I would like to just clarify myself on support. Having to support 3 different platforms (win,mac,nix) causes the developer to have to be prepared to debug in all 3 platforms. MonoGame does a pretty good job making sure you wont have to do this, however, its not fullproof. I know this from past experience. So as for my comment, we already have limitted time and effort being put into this project, adding 2 more platforms stretches that pretty thin. This is what I was getting at when I said "support multiple platforms"

EDIT: Just saw this topic was closed. If you would like to conintue it please feel free to join us on https://gitter.im/ZaneDubya