Small bug introduced... 
KEY() now returns a real (DGint), before this new version is always returned a, integer (DGNat). The manual states that it returns an integer but it now returns a float instead. This kinda messes up my code that uses bit manipulation with the KEY() function TBH.
I could cast it temporarily but KEY() really should return only integers IMHO.
Its on purpose, not a bug. Gamecontrollers is the issue. We do shall update the document.
The reason is the game controllers which some buttons returns a float, so you can support a game pad controller using KEY(). Game controllers is a hell to get right on Android and even the included joy() might mess up on some gamepads as they diddent propert support remapping. Even tilt is routed to KEY() as well.
So if you uses a one player that support gamepad, you should uses KEY() and do a remapping feature to make its would works in thier gamepad. Triggers and Right stick is often the issue which dont follow a standard and sometimes swapped.
But im do have in strings.xml make sure its does not return a float between 0-1, if you dont want that, but here you do require to set a deadzone throught.
But so if you want to support game controllers, dont do bit manipulation at all, if you want analoge support! But if you dont use the analoge feature, just disable it and its return either 0 or 1 as before, but just a float.
TBH this is not great news to me personally.
The KEY() integer problem was really for this bit of code...
INLINE
self.keys = KEY(200)|KEY(208)<<1)|(KEY(203)<<2)|(KEY(205)<<3)|(KEY(42)<<4)|(KEY(54)<<5)|(KEY(29)<<6)|(KEY(157)<<7);
ENDINLINE
Not a biggie, I just cast those but I mentioned it cause it looked like a bug.
But I do have a large and extensive library for GamePads using the traditional GETJOYBUTTON, GETJOYX, GETJOYRX, GETDIGIX, GETJOYZ etc. to name but a few. It already handles, multiple GamePads, types(XBox 1, PS4 ect.), deadzones, remapping of game pads, analogue + digital input and gampad emulation via a keyboard/mouse.
I am feeling that to go down a different input route for Android input should not be the way to go. The GLB input API should be universal and not platform dependant, as it is already now. If there are back-end differences, then they should be emulated under the current API or extended via new commands that complement the current API.
Maybe I have the wrong end of the stick? I hope so. TBH it probably wouldn't kill me at the end of the day I could rewrite my input code for Android.
