So Apple announced it's new Apple Tv with a new OS called tvOS.
According to Gamasutra tvOS is built on iOS, and what's more interesting App size is capped to 200mb - so I think it would be a great fit for LÖVE.
The downside:
the new box has no local storage for developers, meaning all apps must store/retrieve data remotely via iCloud.
I plan to get SDL and LÖVE working on it if possible, however the local storage thing will be a challenge.
The input device (the remote) is also pretty interesting. iOS actually exposes it as a game controller (SDL doesn't have code to deal with iOS game controllers yet though), and it has a built-in accelerometer and touch surface.
slime wrote:I plan to get SDL and LÖVE working on it if possible, however the local storage thing will be a challenge.
The input device (the remote) is also pretty interesting. iOS actually exposes it as a game controller (SDL doesn't have code to deal with iOS game controllers yet though), and it has a built-in accelerometer and touch surface.
seeing that all FS stuff is already streamlined by the love.filesystem API which is looking rather slim, actually there is a good chance of working on it, no?
If the love.filesystem api was lower-level it would be a lot harder to abstract that over network.
love.filesystem is based on PhysFS. IIRC, more recent builds of PhysFS have support for writing custom low-level functions for reading and writing files, which could probably be used to solve the storage issue.
An alternative solution would be to expose tvOS' APIs to Lua and have developers write custom code for saving on tvOS.
slime wrote:I haven't looked at the iCloud API (CloudKit) in too much depth, but it seems it's database-oriented and asynchronous, unlike love.filesystem.
Well yes, but if the love.filesystem calls just block to mask a file query then you can deal with that using threads.
Alternatively the files could be buffered in memory.
I think the idea of exposing the iOS api to lua is more future proof than trying to create an alternate API for it. Still thinking about the future, exposing the Android API would help as well. People can always create a common wrapped API in Lua directly if they feel the need.
gianmichele wrote:I think the idea of exposing the iOS api to lua is more future proof than trying to create an alternate API for it. Still thinking about the future, exposing the Android API would help as well. People can always create a common wrapped API in Lua directly if they feel the need.
It goes against the "write once, deploy anywhere" approach we all know and löve.
T-Bone wrote:It goes against the "write once, deploy anywhere" approach we all know and löve.
Agree but there are some services that you could not possibly think to be able to standardize. Also what I was asking is a simpler binding to those functions not a real wrapper
