Xamarin Problems & Build Changes

I’ve been checking on the progress on the Xamarin front. As you may remember, we are phasing out the Xamarin backend.

It seems the problems with the Xamarin backend are not resolvable. Michael Bayne from ThreeRings has fixed up many things, but it seems many of our users are still having issues despite those fixes. I’m in favor of not releasing the Xamarin backend in the upcoming 0.9.9 release. I would tag or branch the Git repository to keep the Xamarin backend available, then remove all remnants of the Xamarin backend from the repo. The nightlies and release would not contain any Xamarin related things anymore (drastically cutting down the download size of libgdx as well). What are your thoughts on this matter?

Also, i want to kill the unholy Ant build script of death in favor of our Maven build. Reason being that the setup-ui will be transitioned to use Gradle in the near future, and Gradle requires our stuff to be in a Maven repository. By forcing myself to fix up the Maven build (it is up to date and fully functional, including gdx-freetype and gdx-bullet), i can guarantee that the Maven releases are pristine. I’d also like to get input on this.


23 thoughts on “Xamarin Problems & Build Changes

  1. It seems as if a lot of people have been able to port their Xamarin.IOS game to robovm with little to literally 0 effort, and it came with an accompanying FPS boost. People who are currently working on their game can easily switch to robovm (from what i hear!), and people who have already released and dont plan on updating dont require the nightlies.

    So it seems best to do what you said and keep Xamarin tagged, but remove it from the build.

  2. Same as David. Robovm is a strong, free and working alternative. Xamarin should be thanked … and removef.

  3. +1, especially on the build/project support.

    I’m hoping that proper Mavin and Gradel support will allow easier and more reliable NetBeans support. I haven’t tried it recently, but, last time I did, it was a right PITA. I never did get the Android build working right.

  4. While RoboVM doesn’t have needed things for game development like game center or in app purchases I don’t think the Xamarin backend should be removed…

  5. RoboVM has a way to call Objective-C directly. Not sure how it actually works, but it should be able to do both.

  6. Bro bindings, I know. But so far, no one has achieved to make the bindings for any internal ios framework 🙂

  7. Recently (yesterday) I published another project using Xamarin. I do not know how long it will take for us to have a stable version of RoboVM that create IPAs and other necessary things. My suggestion is that the backend of Xamarin remains available until the RoboVM is really an option palpable.

  8. Ya, i guess you are talking about Game Center. It will come just give it time. Others have already bound some ad provider libraries. Niklas is floored with work, so we need to be a bit patient 🙂

  9. Ya, tbh, i haven’t looked into Netbeans support yet. I appreciate any help with the Gradle template in that regard, i’m super inexperienced with Netbeans, and especially its Android integration.

  10. What libgdx version are you using? 0.9.8? Cause the current Xamarin backend is indeed not stable.

    RoboVM already allows creation of IPAs.

  11. I’m using the lastest nightly, but i left my Mac Mini off for a long time and did not make the latest Xamarim updates 😛 .
    I’ll check which version it is and post here.

  12. Ok, so you are working with an old Xamarin version, but you are using the latest libgxd/Xamarin backend code. So, if i created a tag in Git, and put a special download up that includes a libgdx release for that tag, would that be sufficient?

  13. For me would be more than enough. In addition to the improvements of this project that I said, I have no one in sight to the next 4 to 6 months, which would give time for the RoboVM be our only IOS backend.

  14. This would be great. For my multiplayer game I need to export 5 projects to jars and add them to a war file manually because my server is a GWT project and the export to war function doesn’t work well. When you guys release the 0.9.9 version I’ll update my game and start creating pom.xml’s to automate my war generation 🙂

  15. Thank you. I was tired when I posted that and just looked into it. But, again, could there possibly be a PS4 backend in the future since that would open up libgdx to more platforms and also make it much more appealing to more traditional game developers, especially since much libgdx’s code is very similar to XNA (which uses C#). In fact, as a side project, I’m converting many of the XNA games in one of my textbooks from school to libgdx and having little problems so far. 😉

  16. Due to a family medical situation, I’ve got roughly bupkis for extra time right now. That said, I’ve recently paid up for the “extended” version of NBAndroid to get Gradle support, and I need occasional escape time, so maybe I’ll get a chance to take a look soonish.

  17. Event if libgdx is evolving very quickly. I think it still keep many good feature from old version

Leave a Reply

Your email address will not be published.