Input issues on Linux

Discuss ROM-compatibility related issues here.
Post Reply
User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Input issues on Linux

Post by MarathonMan » Thu Jan 29, 2015 12:02 pm

Snowstorm64 wrote:Now that it's fixed, what about this other issue?

...

Regarding that, games on latest version look much better, but they seem to have some control issues, like MK64.

It's very easy to check, you have just to play in any course, and you'll see that the driver will go randomly in any direction sometimes, as if you were going to play an online match with a lousy connection.
I recently made a change to the Linux UI that was supposed to make input get processed virtually instantaneously while simultaneously allowing the UI and rendering to be threaded so people with software rendering don't have to suffer VI/s losses.

That being said, I wasn't aware that it broke the input... I thought it was just more responsive. This will be a bit harder to pin down but I'll look into it because I was planning on doing the same for the WINAPI backend.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Input issues on Linux

Post by MarathonMan » Fri Jan 30, 2015 12:00 pm

@Snowstorm64 (and anyone else who noticed a similar issue):

Are you sure this isn't due to one of two things:

1) Much more responsive input.

2) CEN64's input algorithm (which always assumes that the last key pressed dominates any old keypresses in the reverse direction). i.e., if in Mario Kart 64, if the user is holding LARROW, and then simultaneously presses the RARROW , CEN64 will "forget" that the LARROW was pressed and go hard right as soon as RARROW is depressed.

It doesn't really make sense to simultaneously depress both keys, so if some other action makes more 'sense', I'm all ears. :)

BTW, here's a patch that demonstrates exactly how reactive the new input mechanism is (to support the fact that the input mechanism is not buggy):

Code: Select all

diff --git a/os/input.c b/os/input.c
index 21fdd2f..b1e238b 100644
--- a/os/input.c
+++ b/os/input.c
@@ -26,6 +26,13 @@ void keyboard_press_callback(struct bus_controller *bus, unsigned key) {
 
   if (key == CEN64_KEY_LSHIFT || key == CEN64_KEY_RSHIFT) {
     shift_down = true;
+
+    if (si->input[2] == -114)
+      si->input[2] = -38;
+
+    if (si->input[2] == 114)
+      si->input[2] = 38;
+
     return;
   }
 
@@ -82,6 +89,13 @@ void keyboard_release_callback(struct bus_controller *bus, unsigned key) {
 
   if (key == CEN64_KEY_LSHIFT || key == CEN64_KEY_RSHIFT) {
     shift_down = false;
+
+    if (si->input[2] == -38)
+      si->input[2] = -114;
+
+    if (si->input[2] == 38)
+      si->input[2] = 114;
+
     return;
   }
That change makes LSHIFT and RSHIFT changes take place immediately (i.e., even if you're been holding LARROW with shift not depressed, and then depress shift later, it's equivalent to switching from a "hard" left on the joystick to a "soft" left.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: Input issues on Linux

Post by Snowstorm64 » Fri Jan 30, 2015 1:31 pm

MarathonMan wrote:@Snowstorm64 (and anyone else who noticed a similar issue):

Are you sure this isn't due to one of two things:

1) Much more responsive input.

2) CEN64's input algorithm (which always assumes that the last key pressed dominates any old keypresses in the reverse direction). i.e., if in Mario Kart 64, if the user is holding LARROW, and then simultaneously presses the RARROW , CEN64 will "forget" that the LARROW was pressed and go hard right as soon as RARROW is depressed.

It doesn't really make sense to simultaneously depress both keys, so if some other action makes more 'sense', I'm all ears. :)
The patch is neat, but...Well, I can't surely tell about that, but I'm sure on the fact that sometimes CEN64 suddenly stops taking user input (and in some case it will keep running on the last input, for example the driver will go always to right, even when there's no pressed key). BTW, this doesn't apply only to tracks, but also to menus and character selection, for example the cursor sometimes won't change for any other position even if you press any arrow key, in this case only a key is pressed at once. If it causes problems even with a simple action like scrolling a menu... I suppose that it might be a window focusing issue, but I'm not sure about that. Any thoughts?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
morphology53
Posts: 2
Joined: Mon Jan 12, 2015 10:40 pm

Re: Input issues on Linux

Post by morphology53 » Fri Jan 30, 2015 7:20 pm

I'm reasonably certain that <+> and /\+\/ were valid inputs, or at least it was mentioned as a warning in the official documentation, in the sense that the game itself should deal with it.

Been a very long time since I've looked at sdk stuff, but I believe it was on the same chapter as not doing anything with "L+R+Start"

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Input issues on Linux

Post by MarathonMan » Sat Jan 31, 2015 10:21 am

morphology53 wrote:I'm reasonably certain that <+> and /\+\/ were valid inputs, or at least it was mentioned as a warning in the official documentation, in the sense that the game itself should deal with it.
That's impossible. :p

The joystick only has two axes, and the hardware exposes exactly one scalar value per axis.

The control pad directional arrows can, OTOH, be pressed simultaneously.

User avatar
morphology53
Posts: 2
Joined: Mon Jan 12, 2015 10:40 pm

Re: Input issues on Linux

Post by morphology53 » Sat Jan 31, 2015 1:20 pm

MarathonMan wrote:
morphology53 wrote:I'm reasonably certain that <+> and /\+\/ were valid inputs, or at least it was mentioned as a warning in the official documentation, in the sense that the game itself should deal with it.
That's impossible. :p

The joystick only has two axes, and the hardware exposes exactly one scalar value per axis.

The control pad directional arrows can, OTOH, be pressed simultaneously.
Yeah whoops, I meant the Dpad

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Input issues on Linux

Post by MarathonMan » Sun Feb 01, 2015 6:48 pm

Still scratching my head. Can't reproduce any of the input issues you mentioned. :(

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: Input issues on Linux

Post by Snowstorm64 » Sun Feb 01, 2015 8:07 pm

MarathonMan wrote:Still scratching my head. Can't reproduce any of the input issues you mentioned. :(
Hm...that's strange...Could it be a problem of my PC? Please, anyone of you, that use Linux, can confirm if these issues are widespread or not? Though I should to do further tests, maybe with different settings.

Update: These issues don't occur under Wayland. I'm starting to think that it's X.org's fault, as I had had some similar problems in the past (GPU driver, etc.). MarathonMan, I'm sorry for the wasted time I have caused. :( Although, I think it was a dormant (X.org ) bug that has been uncovered with the recent commits to make the input more responsive.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: Input issues on Linux

Post by MarathonMan » Mon Feb 02, 2015 12:08 am

No time wasted, really, no worries... I'll still keep an eye out for it though. :)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest