api extensions: api discussion

[Jasoco]

A perfect project would include a simple set of tests at load that would determine:

Is the game running on a PC/Mac or is it on a mobile device like a phone or tablet?

If on mobile, what is the native resolution? What other features does the device support? Will it support the features you need? Are there workarounds for devices that don't?

If on Mobile, does it have a keyboard that is physical or on-screen? If physical, allow using keys for input. If not, provide on-screen buttons to perform the commands.

Will your game be rotatable? Or static to either landscape or portrait? If rotatable, offer a callback, much like the Focus callback which accepts true or false for whether the window is focused or not, that will rearrange everything when the orientation changes. Will it accept it in degrees like iOS where it can be 0, 90, 180 or 270, or just "is landscape", "is portrait".

[Robin]

It pays to have sensible defaults, so a game doesn't have to think about mobile phones to be able to run on them. Automatic scaling if the resolution is wrong, for example.

EDIT: it seems that was already implemented.

[miko]

How should phone/android specific api extensions be made accessible ?

things like multi-touch, sensors like accellerometer, magnetic field (compass?), orientation (gravity?), gps, light
and possibly stuff like phone specific popup notifcations, home/menu button overrides, maybe opening map and browser apps...

currently the love-android apk makes them available as love.phone.getSensorList() etc,
including new user-defined callbacks like

function love.phone.touch (action,data) ... end -- for multitouch
function love.phone.sensorevent (sensorid,data) ... end

is there interest/need to agree on common naming/api schemes now for possible future projects like iphone ?
are there maybe love2d ports for handheld devices that already have apis like that ?

I am interested, definitely!
I was playing with a framework for which you can write an application, which then can be run with different "backends". For now, I can run it with love, scrupp, lua+glut, and plain lua - of course, some backends miss some features, but at least love and scrupp are looking the same.

The way I integrated all the callbacks is the observer pattern, implementation inspired by Symfony2: http://symfony.com/doc/2.0/book/interna ... dispatcher

So there are no more love.* callbacks. There is one single eventDispatcher, where I can register for events, like:

Code: Select all

eventDispatcher:connect('system.update', function(e)
  local dt=e:getParameters().dt
  RECTANGLE.x=RECTANGLE.x+dt
  if RECTANGLE.x>200 then
    RECTANGLE.x=0
  end
end)
eventDispatcher:connect('system.draw', function(e)
  RECTANGLE:draw()
end)

This same event system could be using to execute commands to the system, like:

Code: Select all

eventDispatcher:notify(Event(myApp, 'sensor.gps.start', {frequency=60}))
eventDispatcher:notify(Event(myApp, 'sensor.compass.stop'))

(if the platform supported this, it could respond with: 'sensor.gps.started' and 'sensor.compass.stopped' respoectively)
As for multitouch, I plan to write some love example for Dell Latitude XT (with multitouch screen). I could also get some multitouch events from my laptop's synaptic touchpad, but this is not as fun as using screen. So yes, I would be interested in multitouch API even on PC.

What I like about such API is:
- it is back/forward compatible (no need to know the new function names, all info is contained within the event object itself)
- it is not tied to any particular implementation (I plan to write a http server using this framework)
- your old application can report all new events (as "unknown")
- it is easy to generate events yourself (like testing multitouch applications), so you can convert mouse events to keypresses or other way around

Of course, there are two main objections to this approach:
- it is no longer "plain old love API"
- it is OO based, so some class implementation is assumed.

Anyways, maybe you will find this idea interesting.

[ghoulsblade]

This thread is more about how api-extensions (touch,accel,gravisensor,gps...) should be made for stuff that is commonly available on android devices.
For changing the existing love api-event api (mouseclicks, keyboard..) you should discuss with the love main developers first.
In my opinion however one key advantage of the love api is that it is kept simple and easy to use, even for people without much programming knowledge.
So while it might be very elegant oop principles and a good idea for big, extensible applications, is the wrong way here i think.
At least as default api.
Lua is rather flexible and you should be able to offer this as an alternative api lib with lua only code that other projects can simply include,
without changing the core löve binary. If you know your way around metatables you can even set one for _G to print a warning in case the original mousepressed etc are used when your lib is active.