New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for tvOS #4218
Comments
I'm not yet, maybe over Christmas if someone else hasn't done the work by then. |
Is there any chance to speed up this? Right now there's little games for Apple TV and it's almost Xmas... there's a big chance here to quickly port MonoGame games and get a good market oportunity :) |
How much money do you want to spend? That's the most common way of getting things done faster. |
I would lend a hand but I don't know much about MG's architecture. And I see that you're not using PCL, so that would mean making yet another project as it's a whole different platform than iOS. |
I couldn't resist it :) Sorry if I sounded like trying to influence where volunteer developers put their free time. I was telling it more with the perspective that being an unexplored unsaturated apple market (something that hasn't happened in the last 5 years) having MonoGame products up there could benefit MonoGame users. In example, danzel released a few days ago Simpulls, a very nice game that would fit Apple TV very well. Battling the oversaturated iOS store is often an uphill battle for most of us, but the chance to release games to an unsaturated apple market, before Xmas, and without (afaik) Unity3d ports yet is an oportunity which probably won't happen in the years to come. Honestly I wouldn't mind hiring help for this issue to be done. Problem is that I don't know what is the scope of the work to be done, and while I could afford 5-6 hours of development, 50-60 would be totally out of my reach. In factI'd love monetary rewards would be integrated in github to speed up fixes and features, but this also comes with its ownshare of problems. Well, umm... sorry for the generic offtopic rant :) |
It would require someone with a tvOS device to do the work. I don't know who has one yet. |
There's another parameter to this problem: it is required that Xamarin come up with a reliable tvOS support first, which is not quite there yet. We have an Apple TV, but we have no plan on using MonoGame for tvOS yet. We were planning to publish a Unity3D project we already completed to tvOS, but the Unity3D tvOS support isn't reliable ATM (there's definitely many developers missing opportunities because of its lack of a day-0 support, which I don't quite understand). I'm in the same position as others: no time to afford. But I'll keep an eye on this and will gladly help if I can. |
Oh... I sort of took for granted that Xamarin must have already added support for it. @dellis1972 - Do you know what the timelines are for tvOS support from Xamarin? |
Hi, Xamarin says that it's non stable and preview (not even alpha), but also seem to say that things can be done, putting Transistor as an example of software in the apple TV store which is working and using Xamarin. http://forums.xamarin.com/discussion/comment/163990/#Comment_163990 No idea if they're using the same build, though... |
The question is: do one want to redo things twice if the Xamarin API will possibly change? |
Ok... so there is a preview release of Xamarin tvOS support. If someone wants to do the work to add a platform for it to MonoGame that would be great. But of course we will have to fix it when the final release of it occurs. Seems no different than our Win10 experience. :) |
@tomspilman kennethp and I are on it 😊 -----Original Message----- Ok... so there is a preview release of Xamarin tvOS support. |
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This PR addresses multiple issues at once because they're all dependent on one another: * Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here. * Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with MonoGame#4218. * Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the `PLATFORM_MACOS_LEGACY` define. This resolves MonoGame#4275, but should also fix bugs like MonoGame#4278. * WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning. * WindowsUniversal package resolution occurs outside MSBuild: Until the build server is updated, this is necessary to build against an older version of the Windows Universal SDK.
This was implemented :) |
Is anyone working on supporting tvOS?
The text was updated successfully, but these errors were encountered: