Skip to content
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

Closed
tanis2000 opened this issue Nov 3, 2015 · 13 comments
Closed

Support for tvOS #4218

tanis2000 opened this issue Nov 3, 2015 · 13 comments

Comments

@tanis2000
Copy link

Is anyone working on supporting tvOS?

@danzel
Copy link
Contributor

danzel commented Nov 5, 2015

I'm not yet, maybe over Christmas if someone else hasn't done the work by then.

@KakCAT
Copy link
Contributor

KakCAT commented Nov 9, 2015

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 :)

@theZMan
Copy link
Contributor

theZMan commented Nov 9, 2015

How much money do you want to spend? That's the most common way of getting things done faster.

@tanis2000
Copy link
Author

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.
But if you need a hand I've already done that same work with SDL and OpenFL so you can ping me when the time comes.

@KakCAT
Copy link
Contributor

KakCAT commented Nov 10, 2015

How much money do you want to spend?

56026643

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 :)

@KonajuGames
Copy link
Contributor

It would require someone with a tvOS device to do the work. I don't know who has one yet.

@mrhelmut
Copy link
Contributor

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.

@tomspilman
Copy link
Member

Xamarin come up with a reliable tvOS support first,

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?

@KakCAT
Copy link
Contributor

KakCAT commented Nov 11, 2015

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...

@mrhelmut
Copy link
Contributor

The question is: do one want to redo things twice if the Xamarin API will possibly change?

@tomspilman
Copy link
Member

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. :)

@dellis1972
Copy link
Contributor

@tomspilman kennethp and I are on it 😊

-----Original Message-----
From: "Tom Spilman" notifications@github.com
Sent: ‎11/‎11/‎2015 15:32
To: "mono/MonoGame" MonoGame@noreply.github.com
Cc: "Dean Ellis" dellis1972@googlemail.com
Subject: Re: [MonoGame] Support for tvOS (#4218)

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. :)

Reply to this email directly or view it on GitHub.

hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 3, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 3, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 3, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 9, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 9, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 9, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 9, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 9, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 9, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 14, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 14, 2015
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.
hach-que added a commit to RedpointArchive/MonoGame that referenced this issue Dec 14, 2015
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.
@dellis1972
Copy link
Contributor

This was implemented :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants