New input gui#1713
Conversation
| // * You should have recieved a copy of the GNU General Public License | ||
| // * along with this program; see the file COPYING. | ||
| // * If not, write to the Free Software Foundation, Inc., | ||
| // * 59 Temple Place - Suite 330, Bostom, MA 02111-1307, USA. |
There was a problem hiding this comment.
Boston* 😉
We can do this fix later on.
There was a problem hiding this comment.
Didn't we already fix the Bostom=>Boston globally? If so, then it should be fixed here rather than in a later PR.
There was a problem hiding this comment.
Nope, we didn't. Source:
- https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/blob/develop/src/gui/DlgAbout.h#L18
- https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/search?q=bostom&unscoped_q=bostom
You may had been thinking about XbSymbolDatabase which has the correction.
|
Ignore this, native close button doesn't perform the save. |
|
|
Tested with Sdl I'm fond of the stick and D-Pad settings "Up down left right" like old GUI. In addition, the same order as the trigger can be set intuitively. |
There was a problem hiding this comment.
Generally works well in the games I tested. Configuration is, much better than our current input manager/configuration.
One issue I had that is that the purpose of the 'profile' input is a little unclear: Do you think we could provide one preset profile so that users can configure and save their settings without having to come up with a profile name?
The purpose of the 'modifier' input is also unclear.
Another issue is that I was able to lose my configuration by doing the following:
- Create a Profile, named 'Test'
- Configure inputs as you desire
- Save
- Run the emulator, test config, it works
- Open configuration editor, delete your profile, the configured inputs are still shown in the input fields
- On closing the dialog, input was still working as configured
- On re-opening the dialog, all input mappings were lost (due to not having a profile)
Is there any way we can avoid this scenario? Perhaps we can add some text to the dialog to explain how it should be used, or warn the user if they have configured inputs that do not belong/have not been save to a profile?
Additionally, it seems awkward having the order defined as 'Up, Down, Right, Left' rather than 'Up, Down, Left, Right'. probably just a personal preference, but it doesn't seem 'right'.
| // * You should have recieved a copy of the GNU General Public License | ||
| // * along with this program; see the file COPYING. | ||
| // * If not, write to the Free Software Foundation, Inc., | ||
| // * 59 Temple Place - Suite 330, Bostom, MA 02111-1307, USA. |
There was a problem hiding this comment.
Didn't we already fix the Bostom=>Boston globally? If so, then it should be fixed here rather than in a later PR.
Supposedly you have keyboard input in progress to setup then you had accidentally clear it. You'll have to manually re-input 25 fields. You can check if any inputs had occur then show the popup.
👍 Yeah, users will be confuse why there's a profile name field. Then assume it's not necessary after setting up their inputs.
After 2nd review, looks like the native close button just close it. Perhaps add a close button next to clear button? |
|
https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/pull/1713#pullrequestreview-282515069 To follow up @LukeUsher's comment. Once saved then close/re-open, the profile name is blank which should be showing the profile name. |
|
…itching and saving profiles in GUI
|
I think it's still unclear that the user must type a profile name, and cannot simply configure-and-go. |
|
@LukeUsher There is current review change I had requested. Source: https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/pull/1713#discussion_r319782952 Beside that, I had not re-test the recent change at the moment. I will test it out very soon. |
Hmm, supposedly in the future. We may will have default setup for keyboard/mouse. So, it's better to use "Default" button and disable the button if using keyboard/mouse is selected.
Cause by inexperience users or forgot to save new change(s). We'll have to expect multiple false positive report for this. Plus complaints too. |
|
I know that there are still issues and the work is still incomplete. I'm just pushing commits to allow early testing and discover eventual bugs sooner rather than later. |
…le from window class
|
As of commit a001e46, the GUI look complete to me even the recent GUI code changes too. UPDATE: Okay I found one tiny issue, the rumble test doesn't stop until input UI are completely close. |
|
I suppose that happens with SDL controllers? Because with my XInput controller it rumbles for a fixed amount of time and stops normally, independently of the input GUI. I don't have SDL controllers which support vibration so I can't see it myself. |
RadWolfie
left a comment
There was a problem hiding this comment.
Tested with
- Lego Star Wars 1 & 2
- Just Cause
- Star Wars of the Old Republic 1 & 2
- Crazy Taxi 3 - High Roller
Titles above did not regress.
|
"XInput Default" labeled button is present even with dinput/keyboard |
This implements a new input GUI which completely replaces the old one. It uses Sdl input to handle all non XInput controllers (which are instead handled by XInput) and the keyboard is handled by DInput. The appropriate API is automatically selected so you don’t have to select it now like you had to with the old GUI. Code to support the mouse is present but disabled as it has an unresolved issue which leads to weird movements in games and needs more investigation. Rumble functionality has been implemented so your controllers can also vibrate now (tested with XInput, Sdl needs testing). I also made some changes to the Xbox XInput functions so you will want to retest many games to see if I haven’t accidentally broken something. Please note that, according to here JayFoxRox/xqemu#4 (comment) , not all games accept input from ports other than 1. So, if a game doesn’t accept input from a port, try to connect it to port 1 and if it works, than it’s not a regression/bug.
Edit: Ready for merge