Skip to content

Event-based gamepad functionality#1106

Merged
vadi2 merged 6 commits intoMudlet:developmentfrom
dicene:gamepad
Jun 28, 2017
Merged

Event-based gamepad functionality#1106
vadi2 merged 6 commits intoMudlet:developmentfrom
dicene:gamepad

Conversation

@dicene
Copy link
Copy Markdown
Contributor

@dicene dicene commented Jun 19, 2017

Should only be sending the events to whichever window is active, but I could be mistaken. Needs some testing. Note that for Windows users, you're limited to XInput devices, like Xbox 360/One controllers, some 3P controllers, and PS3 and PS4 controllers if you use the right software to spoof XInput with them. Other OS's should have access to all gamepads, although the QGamepad class is only really meant to handle Gamepads ala: https://en.wikipedia.org/wiki/Gamepad and might not function with joysticks/etc

Copy link
Copy Markdown
Member

@vadi2 vadi2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good just one thing

src/src.pro Outdated
macx:QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.7

QT += network opengl uitools multimedia gui
QT += network opengl uitools multimedia gui gamepad
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Include this conditionally like before - I'll build all installers with Qt 5.9 but we have min 5.6 ATM for Linux distros.

dicene added 2 commits June 19, 2017 15:17
Should be safe to compile on versions of Qt < 5.8
@vadi2 vadi2 requested review from SlySven and itsTheFae June 19, 2017 19:20
@SlySven
Copy link
Copy Markdown
Member

SlySven commented Jun 20, 2017

Note that for Windows users, you're limited to XInput devices, like Xbox 360/One controllers, some 3P controllers, and PS3 and PS4 controllers if you use the right software to spoof XInput with them.

Probably another instance of Windows security which does not let user level code have access to USB HID devices that are identifiable as keyboards or mice (some of the latter can send the equivalent of keystrokes under some circumstances) to try to prevent the installation of key-logging software... 😈

Also, can you pin down when qtHaveModule(...) made it into the qmake vocabulary - I do not think it was in Qt 5.0.2 which is fine but it needs to be in all the Qt versions that we DO support so that means checking back into the Qt 5.6 documentation!

@dicene
Copy link
Copy Markdown
Contributor Author

dicene commented Jun 20, 2017

On an initial glance, I see a post on a Qt forum from 4 years ago that mentions qtHaveModule as new at that time.

@dicene
Copy link
Copy Markdown
Contributor Author

dicene commented Jun 20, 2017

Apparently there are slot related problems that don't compile in one of the tests Travis is doing. I see a fix was applied later on. I'll see if that fixes the issue.

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Jun 20, 2017

I think if you change it back and put a & in where the ^ is pointing to, it'll work. If I'm right, go read https://www3.ntu.edu.sg/home/ehchua/programming/cpp/cp4_PointerReference.html#zz-1, that's where I got my knowledge on that from.

macx:QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.7

QT += network opengl uitools multimedia gui
qtHaveModule(gamepad): QT += gamepad
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need the same thing for CMake

@itsTheFae
Copy link
Copy Markdown
Contributor

I do happen to own a Logitech F310 which supports Direct input and XInput modes. Currently waiting for the Qt 5.9 stuff to finish installing and then I'll be able to test with it. :)

Copy link
Copy Markdown
Contributor

@itsTheFae itsTheFae left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works out nicely, all the expected buttons and axis work. I only have an issue with connection and disconnection as they don't seem to be raised at all for my setup. Qt's debug console prints Gamepad: Could not read from input device (No such device) when I unplug my controller and unless it is plugged in when Mudlet starts the controller isn't noticed or connected later.
I half suspect either the age of my controller or perhaps driver configuration is mishandled by Qt. This is all in XInput mode, just to clarify. I'm not worried about Direct Input since it has been deprecated for some time.
I've had similar issues with controllers in Unity so this isn't totally unexpected behavior, imo.

[Edit]
Did a bit of digging on this and the issue I have is already reported in the bug tracker here:
https://bugreports.qt.io/browse/QTBUG-57078

@vadi2 vadi2 added this to the 3.3 milestone Jun 21, 2017
@dicene
Copy link
Copy Markdown
Contributor Author

dicene commented Jun 21, 2017

For reference, here's where I got the impression Windows support isn't going to really improve for Gamepad over time: https://bugreports.qt.io/browse/QTBUG-57389?focusedCommentId=346127&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-346127

I'd really prefer access to DInput as well for a number of reasons, especially since a lot of accessibility devices will work with DInput but not XInput. Seems it's not meant to be though.

@itsTheFae
Copy link
Copy Markdown
Contributor

I did test the Direct input mode and the current code does seem to register two axis (one joystick) and one of the buttons on my specific controller. With that I gather some extremely basic joystick input devices can work.
@vadi2 has asked how to enable the SDL back-end for QGamepad on Windows. That might require SDL2 sources or at least as much as is needed for SDL_Joystick, but it might also help with some of the issues and maybe bring a bit more general support for Direct Input and other devices too.

@dicene
Copy link
Copy Markdown
Contributor Author

dicene commented Jun 22, 2017

The only part that's really hard after getting that going would be getting analog sticks handled properly. I've not dealt with the sort of math required to implement a proper deadzone in a long time, but I might be able to figure it out over time. The fact that it can't be made to work with a DS4 or similar controller just connected via bluetooth without a third party program like DS4Windows running to emulate an XInput device is what made it feel so incomplete to me.

@itsTheFae
Copy link
Copy Markdown
Contributor

I've come to expect the need for special drivers or applications to get most third-party stuff to work nice on windows. At least there are applications like http://www.x360ce.com/ that could help with with emulating XInput for older DirectInput controllers on windows.

As for the deadzone math, that shouldn't be too hard. From my experience in Unity, input axes are usually able to return values from -1.0 to 1.0, where 0.0 is "centered" but since joysticks may not always come to rest exactly at (0.0, 0.0) after they are moved Unity recommends a deadzone between about -0.2 and 0.2.
For our implementation here, this would basically be the same as checking the input value for falling within that range and if so the value pushed to Lua in the event is changed to 0.0 rather than whatever value was recorded from the device. (though this might also cause multiple events with a 0.0 value to be raised)

I think for now the deadzone math can be carried out in the lua scripts, so as to keep the most raw information available to Lua while we learn about the quirks of QGamepad and other conditions that might effect this cool new feature. :)

@vadi2 vadi2 merged commit 9e9f2dc into Mudlet:development Jun 28, 2017
@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Jun 28, 2017

I'll merge this PR in as it's been sitting ready for over a week now and has been reviewed by most people on the team. If anything is wrong with this, we can always fix it up in another PR!

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Jun 28, 2017

@dicene this needs some pretty good documentation now else it'll be inaccessible save for the hardcore scripters - could you document all of the events + make a sample demo package to demonstrate how to use this?

Something like I did to demo coroutines or one-line installs.

vadi2 pushed a commit that referenced this pull request Jul 2, 2017
@dicene dicene deleted the gamepad branch May 5, 2018 16:59
vadi2 pushed a commit that referenced this pull request Jan 12, 2019
* Removed duplicate clear event handlers call

* Revert back to dev version. 3.3 here we go!

* Adds saveWindowLayout() call to AutoSaveOnExit processing.

* Edbee editor implementation (#985)

* Added a frame to edbee so it looks nicer

* Got utf8 module to load (#1074) (update packaging!)

* Modified tooltip for Save and Save Profile to clearly indicate their keyboard shortcuts

* Added: shortcut for delete action in editor (#1084)

* shortcut added for delete action

* Removed redundant edbee config related code (#1091)

* Delete TScriptEditorManager.h

* Delete TScriptEditorManager.cpp

* BugFix: import some fixes by "Zolder" from Mudlet (Realms of Legends) fork

import: some Zoilder fixes from the MudletRL fork:
* in TBuffer::translateToPlainText(...): make some MXP related code execute
  only if Host::mFORCE_MXP_NEGOTIATION_OFF is NOT set as well as another
  condition.
* in TBuffer::wrap(...): change a for(...) {...} loop termination condition
  be a "<" rather than a "<=" test - which sounds like an "off-by-one"
  error fix-up.
* In TTextEdit:updateScreenView(): revise code that seems to prevent the
  width of a "main" console being set too small and NOT written to the
  "parent" Host::mScreenWidth variable - the original modification
  removed such a restriction completely, but I have just lowered the
  minimum from 100 to 40 and ensured it is always stored both in the local
  "main" console and to the parent record in the Host class for that
  console.
* In TTextEdit::drawForeground(...): revise the behaviour *I think* when
  at the point where a console "split" becomes unnecessary...

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

* Cut down on the length of some variable names (#1086)

* Clarified use of QLatin1String

* Adding GCC 5 for C++14 requirement (#1098)

* Fixed "reset map colors" button to work (#1049)

* Fixed "reset map colors" button to work

That's a 5 year old bug out of the way!

* Change travis configuration to use installed gcc-5 (#1108)

* Change travis configuration to use installed gcc-5

* Fixes #1104 (#1109)

Thanks to Rick for his prompt response on this

* Fixed typo in GeyserLabel.lua

Per #1112

* Fix locale to C

Enforce uniform locale so scripts don't get tripped up on number representation differences (. vs ,)

* IRC client update of UI and logic (#1072)

* Add Communi Model & Util libs

* Full refactor of IRC Client code & UI

This retains the primary functions of the old IRC client but adds many
more new IRC commands by default. The UI is slightly more organized and
interactive now.

* Adds QPointer to IRC Dialog pointer variable.

* Update Lua `sendIrc()` slightly.

* Added /msg command, Input History, and updated display colors.

Input History stores a total of 8 previously entered commands the user
can cycle through using the Up Arrow key.
The previously include /msg command has been added again.
Colors of some messages have been updated for (relatively) easier
distinction of message lines.

* Updated channel handling.

* Fix CMake builds

Things needed to fix CMake builds:
- communi CMake builds needed `include_directories` explicitly specified
- more MOC calls in communi
- more explicit dependencies to MOC files in communi
- ircmessageformatter must be compiled into mudlet

* IRC3 with more Lua features (#1087)

Changes IRC client to run with settings given per-profile, making the IRC client more visible and configurable within Lua.   
This adds configuration options to the settings window in the "Special Options" tab for configuring an IRC client on the host profile which opens the settings window.   
See the PR summary comment for details on available Lua functions and IRC Client commands.

* Add a Code of Conduct (#1110)

* Create CODE_OF_CONDUCT.md

* Fix for the QMake warnings caused by the IRC library includes.

* Finished formatting all filed & added braces (#1115)

* Finished formatting all filed & added braces

* Re-enabled map load on profile load (#1118)

* Re-enabled map load on profile load - disabling it broke scripts that relied on map data w/o the map open

* updated assignments.

* Event-based gamepad functionality (#1106)

* Add theme switching to code editor (#1095)

* Fix more Toolbar & Button bugs (#1080) (#1090)

* Fix bugs with Buttons & Toolbars.

- Fixed change detection for location, orienation, and CSS data.
- Buttons are not rendered unless they are part of a group,
Toolbar/Menu.
- ToolBars whos locations are changed now hide their previous TToolBar
or TEasyButtonBar instance as needed.

* Fix Buttons being left behind when parent toolbar is deleted.
Also allows TAction to use QPointer<T>

* Update old sourceforge page links (#1132) (#1134)

* Fixed blank command separator to not separate as people expect

* Replaced isTempKey, isTempAlias, etc with isTemporary (#1102)

* also pushed isFolder() and setIsFolder() to the parent Tree class

* Give meaning to encodings (#1107)

* Delete dev_README

Deleted outdated dev_README file.

It also didn't seem to be used all that often, else people would have raised the fact that it's outdated...

* Update travis to use Qt 5.9 for compiling (#1141)

* Re-add single QT 5.6 build job

Since we want to keep sure that the minimal Qt version is still compilable (currently we need at least 5.6), we add a single job for that version.

* Refactor: rename QMake project/sub-project files (#1103)

* refactor: rename QMake project/sub-project files

It is down right confusing having several project files in the Qt IDE
which are all labelled "src" - this commit renames the main project file
from "src.pro" to "mudlet.pro" and also renames:
* the lua_yajl module from src.pri to lua_yajl.pri
* the luazip module from src.pri to luazip.pri
it also:
* adds a new communi.pri file (see below)

I also took the liberty of renaming the project resource file from:
* mudlet_alpha.qrc to mudlet.qrc (we are well past the alpha stage now!)
and sorting a couple of items into the right order.

By creating a local project file 3rdparty/communi/communi.pri it is
possible to group the three separate but related communi libraries into
one - as it happens the effective content of the new file is identical to
that of the communi libraries own libcommuni/src/src.pri but it has some
notes on how the portion of the upstream library that we are using was
picked out of there; how to identify the effect version and how to
(hopefully) recreate things if upstream gets revised in the future!

By not using the upstream "src.pri"/"src.pro" files we avoid the confusion
of having a generic "src" project in the Mudlet project as a whole and it
is clearly identify-able as a file from the Mudlet project rather than the
sub-project that it pulls into the whole thing...

There is an minor nuisance side-effect in that having the main project
src.pro file open in a Qt Creator IDE or stored in a session will get
confused when this commit takes effect as the file will disappear from
the repository - it will be necessary to close the project and open the
new src/mudlet.pro project file (and possibly re-enter the build steps)
- OTOH the main project will now be identified as "mudlet" in Creator
rather than the previous "src". 😄

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

* Removed accidental debug echo left in (#1151)

* initialize int nIrcPort with dlgIRC::DefaultHostPort value. (#1153)

* Removes false from sendIrc() return, ignores command filtering status (#1154)

* Removes false from sendIrc() return, ignores command filtering status (not used).

* Remove punctuation from lua messages

* Improved layout of IRC preferences (#1152)

* Fix get map events (#1120)

* Adapt addMapEvent error messages to current standard
* Fix getMapEvents()
The function now returns a proper indexed table of objects that each describe
a map event.

* Add missing call to set Editor as editable. (#1159)

* Fixed tab indent to be two spaces again

* Fixed getComputerEncoding in case no key found

It'll now return the original value passed - it's way better than returning the wrong value.

* Add linux ci deployment (#1128)

* Modify files needed for CI deployment of linux builds

* Syntax fix in .travis.yml

* tar the CI AppImages as well

* Add lua sqlite runtime dependency

* Unset LD variable for linuxdeployqt

* Bugfix: unset LD_LIBRARY_PATH in every codepath

* Test: install appmenu-qt5 for global menus

* Revert 781ef97 (Install appmenu-qt5)

The issue was that the first AppImage used Qt 5.6.2 instead of Qt 5.9 (which is how 3.2 was built and how it is build now after merging development in)

* Remove manager again (#1163)

* Improved map load output to be condensed down if it's all successful (#1117)

OK! Would be happy to see that in as well for maps that take a while to load (>1s).

* Re-enable search highlighting (#1096)

* Remove mainwindow statusbar (#1162)

* Replaced statustips with tooltips in the mapper menu

* Removed statusbar

* Tagging 3.3.0

* Initial QTextToSpeech additions

* Further TTS additions and bugfixes

* Wrapping TTS functions in #ifdefs for QT_TTS_LIB

* Missing #ifdefs

* More misplaced #ifdef lines for TTS functions

* More QT_TTS_LIB ifs

* Adding QTextToSpeech to cmake lists

* Various TTS updates

* Adding GetState to TLuaInterpreter.h

* Minor fixes

* Tts temporary fixes

* Exchanging toLatin1 with toUtf8

* Fix cmake TTS module includesion

* Install Qt 5.9 TTS module on linux

* Use Qt provided definition for enabled modules

We don't need (and possibly don't want) to provide our own definition for when a module is enabled. Let's use the Qt provided definition instead.

* Output confirmation messages of enabled Qt modules

* Use upper case "Gamepad" in output

* ttsClearQueue crash fix

* Fix for global speech events

* Whitespace replacement

* Various minor fixes

* More minor fixes.

* Cleanup: make CMakeList.txt have uniform indenting and adjust CMake message

The minimum versions of the Qt TextToSpeech and Gamepad reported in the
CMake project files needed tweaking.

I have also tried to regularise the indentation in the Mudlet CMake project
files to standardise on 2 spaces.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

* Reformat: clean up code-loyout of new TTS TLuaInterpreter code

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

* BugFix: fixup a switch() in (int) TLuaInterpreter::ttsGetState(lua_State*)

This switch was missing "break;" on all the cases and must have been
defective without them - for all but the last case extra strings would have
been pushed onto the lua stack but as the return value was 1 they may have
been discarded...

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

* Enable Qt 5.9 Windows builds for testing

* Deploy Qt 5.9 builds for testing

* Fixing double-events for queueing purposes

* Added missing symbol

* Added missing symbol

* Updating tts events to globals and adding voice

* Create TTSValues.lua

* Adding TTSValues to LuaGlobal

* Adding TTSValues to Mudlet project

* Update CMakeLists.txt

* Update TTSValues.lua

* Update Qt to 5.10 for trusty

This is needed to hopefully have some TTS backend plugins in Linux

* Queueing and crash fixes

* Renaming tts funcs

* Renaming internal functions

* Adding functions for retrieving settings

* Fixing typo

* Making ttsGetState public

* Improve error messages for ttsGetCurrentLine()

It can be incredibly frustrating to just get a boolean back as an error message when you don't know what is going on

* Update error message to be consistent with the new style

* Aligned error messages to be consistent with the new style

* Fix ttsClearQueue to return nil+error, not actually error on invalid index

* Minor code formatting

* Floats to doubles

* Update documentation links
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants