Controls update and joystick/gamepad

[Buom01]

Hi, Today I will open this pull request. It main goal is to enhance user input a lot (accessibility, ....) and add complete Gamepad support.

NOTE: To have proper gamepad and haptic feedback working, it must not have custom QVM.

News: --- Bulk commit ---

• Focus effect on listbox
• Show binds in brackets
• Allow color in emoticon's name to make use in binds
• Up to 3 binds, wrapped in brackets
• Colorize bind according to team
• Some emoticon for binds
• Review tutorial text position, opacity and shadow
• Make RED more light (restored)
• Enable joystick by default and review default sensibility
• Allow reversed / negative range input
• Lot of UI controls handling / improvement
• Allow navigation with arrows key (draft)
• Reverse TAB with SHIFT
• Add haptic support
• Other various fixes as CURL path (https://github.com/GrangerHub/tremulous/pull/110/files#diff-87588ca2e05795f8076c4338494baed5) when USE_LOCAL_HEADERS is enabled

--- In individual commit ---

• Old fashion shadow (text) where restored: abusing of it kind of graphical/buffer overflow bug
• Gamepad icons
• Multiple tutorial mode (gamepad/mouse/auto)
• Printf all input error (is it a good idea or should I revert it to DPrintf ?)
• Default gamepad binds
• Joystick / Haptic feedback selection in UI
• Refactor gamepad code, also its threshold
• Solve strange behavior with analog up/down pressed at the same time
• Disable running when moving slowly with joystick
• Replace j_forward, j_side, j_up by a out dead zone threshold, else it make no sense to use a factor since output will be clamped to 64 or 127
• Repair (gamepad) strafing
• Show threshold graph
• Create gamepad feedback effects (done for lcannon only)
• Back button should close sub-popup of the main menu. Escape touch keep its behaviour
• Arrows navigation (almost fully working)
• Repeat a key on long press in UI. Moreover it should handle analogical pressure. (In progress)
• Change tutorial mode appearance. I will probably re-change it again in newfonts branch

Breaking change:

• Remove defaultbindX from code. The only place it were used it was instantly rebound by default.cfg
• The BUTTON_WALKING flag is added only depending of the speed, it will not depend of what controls you press anymore.

FIXEME:

• Are terminology "Global in dead zone" and "Moves out dead zone" correct ?
• Sometimes (even rarelly) the game crash if the gamepad was disconnected unexpectedly ERROR: Q_strncpyz: NULL src.

Need testers for:

• Ball joystick : It should work like a normal mouse
• Any joystick : Should be configurable and usable (its button too), also in patched UI, and buttons name must have consistency

In progress in other pull request / branch (based on current):

• Review fonts: https://github.com/GrangerHub/tremulous/pull/113
• Controls modifiers: https://github.com/Buom01/tremulous/tree/controls_modifiers/ (could be long to do, and boring due to compatibility issues)
• toggle items (/packs) binds: Will be in a separate commit

Other idea for other pull request:

• Fix tab order of comboboxs. Also comboboxs should integrate it's own label
• Restore scannerShader for helmet
• Try to keep selected item in listbox on update
• Focus animation (pulsing slowly)
• Other UI animation (list lists scrolling transition)
• Don't show current team in team selection menu
• Allow to play split screen (maybe with multiple instances)
• Make joystick configurable for UI (only gamepad was binded in code for UI)
• VoIP support (adding it or showing it in the UI)
• Bring back cinematics with mp4 WEBM
• Bring RGB feedback https://gitlab.com/CalcProgrammer1/OpenRGB
• Show gamepad status (ie power level). (SDL is unable to find my device power level)

[dGr8LookinSparky]

Howdy @Buom01 ! This sounds like an awesome pull request, I look forward to it being ready, keep up the excellent work! I appreciate the work you have done, and the work you are continuing to do!

I do have a major feature suggestion for the human buy menu, something I've been planning on, but since you now have some good familiarity with the ui and menus, perhaps you can beat me to and include it as part of this pull request.

Basically I'd like each weapon/upgrade in the human buy menu to have a toggle button associated with it, where if it is not pressed in you don't have the item, if it is pressed in, you have the item. As an example in the case of the batter pack: If you don't have the batterypack, it is available in the stage, and you can afford it, then pressing down the button associated with the battery pack, would buy the item for you, and then the button would remain pressed in for as along as you have the batterypack, if you then press the button again, then the battery pack would be sold. If you lose the battery pack by some other why, like from dying, that button would be reset accordingly (that is next time it would appear unpressed since you wouldn't have the battery pack anymore). If you have a conflicting item, like in this case lets say you have a jetpack before buying the batterypack, when you buy the battery pack, the jetpack would be automatically sold with its button automatically adjusted accordingly.

Probably a good approach is have the items you are carrying be the primary factor in determining the state of the buttons associated with each item, and depending on the state, pressing the button would either buy or sell.

Another part of this feature request is to have a new kind of menu "object" for generating a grid of buttons, because the specific weapons/upgrades should not be determined by the menu scripts, but generated from the QVM based on which weapons/upgrades exist in the code (since that would change with the different game modes we have, and for mods). This menu should have multiple button grids to be able to organize the weapons/upgrades into serpate categories, and sub categories. Like one grid might have just the battery pack items, another might have just the armor items, another might have just grenade like items, another might be for other misc upgrades, etc...

The buttons should have two additional states, one for indicating that it isn't available in the current stage (perhaps don't display that button at all, but make sure that all buttons in the grid would remain in the same spots whether they are displayed or not, so that muscle memory would always know which areas of the menu to move to for each item), another state for indicating that you can't afford the item (perhaps having the button greyed out and unable to toggle). All for of these states should be able to update in real time while the menu is open.

To allow for smaller buttons, weapon/upgrade icons should be used for labelling the buttons. When hovering over a specific item button, the information for that item would then be displayed in the new infopane. A couple of other small panes could be used to display the item name and the price when hovering over the given button.

This toggle button grid approach might work well for the alien evolve menu too, and maybe even for the build menu as well.

Regarding missing commits in the last pull request, I'm not sure why that would happen, although maybe that is the result of squashing those commits into one big commit with the pull request merge. Compare the suspected missing commits with that big squashed commit to see if it is a part of it or not, if it is, I recommend changing the master branch commit history on your local repo to match our master branch on the GrangerHub repo, if this current branch for this pull request has a different commit history from GrangerHub's master branch, I suggest doing an interactive git rebase (see https://git-scm.com/docs/git-rebase ) this branch onto the updated master branch (it is recommended to work on pull requests in new feature branches instead of directly on the master branch for that reason). If the suspected missing commits are actually missing from that massive squashed commit, then if you have them included in this pull request, not to worry they'll be included when we accept this pull request.

Regarding the issue you brought up in regards to the website, I just now brought that to cron's (aka romdos') attention, and I also recommended to him to reach out to you to discuss what can be done with the website. If you're interested, we have also started working on another related project which would require an additional website (that would be linked with the GHub forums), that would include game engine integration with the website to allow for various new features like game statistics, global name registration management, admin features through the website, etc, and someone familiar with html, css, and python would be very helpful for getting that up to speed.

[Buom01]

• Git is cancer, even after successful rebase I will solve this problem, but that's really bad. It should be quite intelligent since the time it exist to see that that's exactly the same commits, since fork should be kind of branch (in a way) Now solved

• About the 'toggle' inventory key system you talk about, I think I will probably try to do it, but in a separate commit. Actually I already wrote code that automatically remove conflicting item (partially working a least). Creating a "toggle item" is not hard, but it may be complex to organize the UI. To be original I think that it could be configured in armory itself, since all items (even locked) are shown.

• I wanna to develop gamepad feedback, but linux system don't send these instruction to my PS3 controller. I will probably need help of anybody which have a full working one. I have already tried a lot of PS3 emulator. All sucks (not working or simulate keyboard). I will make a debugging UI with vibration graph, but I don't know when I could test it in practice since COVID-19's confinement.

[Buom01]

Hi, I consider my work as done. However, I would like to reopen the same PR with less small commit, and no buggy commit (as git rebase caused a lot of troubles, even if the final is OK) It will also allow me to self-review my code as this kind of PR is hard to review.

I close it for now and will reopen it later.