Added Joystick:setVibration(left, right), Joystick:getVibration, and Joystick:isVibrationSupported.
left and right are numbers between 0 and 1 which correspond to the strength of the gamepad's left and right rumble motors, if it has them.
luax_pushtype keeps the object in a weak table and checks the table before creating a new userdata, so it re-uses the object's existing wrapper userdata if it can, whenever the object is pushed to Lua.
This fixes some subtle issues with love objects, where using them as keys in tables would not always work as expected (https://love2d.org/forums/viewtopic.php?f=4&t=39398&p=112388#p112415). It also decreases the amount of new Lua objects created, saving the garbage collector some work.
- Added love.system module, including clipboard functions.
- Added custom hardware cursors (love.mouse.newCursor, love.mouse.setCursor.)
- Revamped love.joystick:
-- added Joystick objects and moved love.joystick functions which operated on individual joysticks to methods on the Joystick objects.
-- Added love.joystick.getJoystick and love.joystick.getJoystickCount.
-- Added events for when joysticks are connected and disconnected.
-- Added 'Gamepad' methods to Joystick objects: Joystick:isGamepad, Joystick:getGamepadAxis, and Joystick:isGamepadDown. They're a common abstraction for xbox controller-like joystick across operating systems.
- Added monitor choosing support and "fullscreen desktop" mode to love.window.
- Moved unicode text input events to their own callback function (love.textinput), removed the key repeat functions from love.keyboard and made the second argument of love.keypressed a boolean saying whether the keypress was a repeat.
- liblove now works with love.window and love.graphics in OS X
Users (or lovers) do not get to choose which implementation of
a module they would like to use.
The abstraction is for dealing with portability issues, not
for giving people the ability to choose an alternative
(inferior) backend. The best choice for any platform/situation
should at all times be the *default* for that platform/situation.
If this is not the case; it's a bug (that is easily fixed).
Any module should provide the functionality promised in the docs.
The lover (or user) should not care how, and if [s]he does, [s]he
does still not get to choose.
Also, a related note: duplication of wrapper code is something I
especially wanted to avoid when I first (or should I say ...
"eventually") formed the current architecture.
--HG--
branch : minor
Alex Szpakowski
Bart van Strien
rude
Bill Meltsner
Bart van Strien