likethemammal / gamepad-micro Goto Github PK

• Error when no callback is given to onUpdate
• Error when GamepadMicro is called with new keyword
• Warn when onUpdate is called when Gamepad API isn't supported

The way the button pressed is written now, the button on fires if it was pressed completely (to value 1.0) and then released. This should be given more lenience.

There should also be a way of telling if a button is being held, and if multiple buttons are being pressed/held.

• Pressed
  • On keyup, if not held
• Held
  • On keydown, after 50ms delay

Would you accept a pull request for a function that clears the released buttons from the gamepad object?

The gamepad object is so conveniently structured that it is helpful to use it as the actual games storage of that data. But this leads to stale data for released.

Currently the released property can be true for an infinite amount of frames even though the button has long been released. It will only be updated when a new event occurs.

It'd be helpful if there was a function we could call like gp.clear() that gives the library permission to clear all released values and buttons. That way the developer can let you know they have processed the user input and you don't need to wait for the next action.

This could be done on a per game/application basis. But seeing as this library is already pretty high level, I hoped it could be implemented directly.

It also may be more performant to do so in the library as there is more information about what buttons need to be cleared, and this could remove the need to loop over the structure.

(Great library btw!)

Not sure when a gamepad might be non-standard, but the code explicitly checks that its standard so this may be causing bugs for ppl with unpopular controllers.

W3C Spec on 'standard' mapping type:
https://w3c.github.io/gamepad/#idl-def-GamepadMappingType

Because non-standards may have weird axis, dpads, and what not this will require some investigation, and maybe some reworking of how the raw gamepads are parsed.

The gamepads are sorted by their indices given by the Gamepad API. This is great and all but it leads to trouble when you try to loop over the gamepads. All the gamepads should be pushed to an array in order and their indices should be track on the gamepad object itself.

Theres two different values for tracking whether a gamepad has connected or not. Theres some bugs related to this, so its worth just consolidating gamepadconnected into gamepadConnected, and having that one source of truth.

Add files list to package.json to ignore most files when publishing to npm. https://www.npmjs.org/doc/files/package.json.html#files

• Some of the utility functions can be moved to vars so they'll be minified
• Gamepad.prototype could be made into a var so it'll be minified
• navigator and window can be made into a vars
• create variables for any strings ('gamepadconnected', 'gamepaddisconnected')
• turn multiple traversals into objects into variables
• Replace instances of true and false with trusted immutable variables
• Only one var statement per func
• console.warn into variable when its being used
• strip out console.log with https://github.com/alanshaw/stripify

Source of some helpful tips:
http://www.slideshare.net/nzakas/extreme-javascript-compression-with-yui-compressor

Add some testing to the lib. Whatever type of testing will work. Need more confidence that the library is stable.

Tape sounds like a good option

Originally reported in likethemammal/daisywheeljs#25

Here's some info:

• Platform: Windows
• Browsers tested: Google Chrome 63.0.3239.84 (64b) and Firefox 57.0 (64b)
• Controllers tested: Generic Xbox 360 controller and Hori RAP 4 (DS4-emulative)
• http://html5gamepad.com/ recognizes the controllers properly, even when both of them are plugged in
• http://likethemammal.github.io/gamepad-micro/example.html recognizes neither, even one by one
• Steam is likely to be interfering with the controllers, but I didn't find any difference with it being off