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".
api extensions: api discussion
- Robin
- The Omniscient
- Posts: 6506
- Joined: Fri Feb 20, 2009 4:29 pm
- Location: The Netherlands
- Contact:
Re: api extensions: api discussion
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.
EDIT: it seems that was already implemented.
Help us help you: attach a .love.
Re: api extensions: api discussion
I am interested, definitely!ghoulsblade wrote: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 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)
Code: Select all
eventDispatcher:notify(Event(myApp, 'sensor.gps.start', {frequency=60}))
eventDispatcher:notify(Event(myApp, 'sensor.compass.stop'))
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.
My lovely code lives at GitHub: http://github.com/miko/Love2d-samples
- ghoulsblade
- Party member
- Posts: 111
- Joined: Sun Oct 31, 2010 6:11 pm
Re: api extensions: api discussion
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.
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.
love-android - gamejams
Who is online
Users browsing this forum: No registered users and 6 guests