Several improvements on the JS side.

medape commented 5 years ago

It looks like I wrote over every file, but I separated my edits into different commits. I'll try to summarize the end result:

Vibrations

Yoke won't longer vibrate when releasing a control (no more VIBRATION_MILLISECONDS_OUT). Controls still vibrate when touched (VIBRATION_MILLISECONDS_IN).

Testing a fast-paced retro game made me realize that, when I release a button, I notice the vibration in the joystick hand. That was confusing and tired my hands in a couple of minutes, because I felt vibrations for half the time. Letting your fingers off the screen is good enough feedback.

I also decreased the vibration on changing quadrants (VIBRATION_MILLISECONDS_OVER).

Joysticks

Joysticks now vibrate more strongly the farther you drag your finger off the area. This is a bit more helpful to find your way back to the joystick center without looking at the phone.

This function can be disabled with the flag VIBRATE_PROPORTIONALLY_TO_DISTANCE (name pending), so that's one more flag we have to take into account for #33.

Joysticks have now an internal range of [-0.999999, 0.999999] because it makes some calculations easier. I was worried that it would slow down the controls, but it looks fine in emulators under Linux so far. (This only affects the JavaScript side: they're still mapped to [0, 255] for the Python code, so this change shouldn't change gameplay.)

General cleanup

I reversed a couple of decisions in the JS; I removed the vibration queueing from truncate() (it would only be useful in pedals and not really worth it) and split mnemonics() in two different functions: new mnemonics() to one to parse the CSS grid codes and find the relevant control, and categories() to sort those codes before sending them to the Python code.

I also moved some things around, added some comments, and improved the alert box in the Yoke webview (I don't issue duplicate warnings anymore, and warnings are queued until the user has read them all. Users shouldn't receive any warnings unless they make a lot of mistakes with their CSS.)

D-pad

This is the change I'm personally most happy with, although it reverses one of my decisions and made me change four of your images. Remember when I said that we could make a working D-pad out of four digital buttons?

I was wrong. Very wrong. The only way to change directions with four buttons was to move your finger away and press a new button, as sliding your finger wouldn't change your direction. This is uncomfortable, and I also noticed later that it made it impossible to move diagonally unless you used two fingers to press two buttons. (Assuming your screen can correctly detect two fingers in the same spot.)

In a real D-pad, you can slide your finger to press different buttons, or even two perpendicular directions with one single finger. To emulate that, Yoke draws a D-pad on a single grid area (code dp), and while the finger is on this area, tracks the finger position and checks it against four overlapping hitboxes. Up and down don't overlap in this version, and neither left and right, but you can quite easily move diagonally in games that allow you to.

There's also an extra benefit: the D-pad itself snaps to the grid as usual, but the legs of the D-pad needn't. D-pads can now be two squares wide or four squares wide if we want them to be.

I tried to use CSS masks to allow users to change the background directly from CSS, but I couldn't get it to work in the Webview. For the moment, it's using dp.svg as a background, which includes the plus-sign-shaped body and your icons for the old du, dl... buttons.

Knobs

Knobs are more realistic and easier to use. Before, you had to make sure you put your finger on the small circle, or the knob would instantly turn to meet your finger.

Now you can turn it as a real one. No matter when you touch it, a quarter turn with your finger will always translate to a quarter turn in the Yoke virtual device.

Racing controls and spinners

The racing layout looks a little more like a modern driving wheel controller.

I also added spinners for the gyrometers. They always spin in the opposite direction they measure, so if you incline the screen towards you and have a tile for the gamma angle, the spinner will spin away from you so it looks like it's fixed in perspective.

Or that was the idea. It will never be so life-like, but it's still very helpful for users and developers alike to notice what they're supposed to measure.

(True to my non-existent art skills, the current spinner is a single capital M. You can use a proper icon by replacing img/motiontrinket.svg.)

Spinners for the accelerometers don't move or distort yet.

Button icons

I didn't redraw your images for the buttons: I just removed some useless attributes on them, and tweaked the generator. And renamed all of them. That's why it looks like I changed everything.

I also created icons for the analog buttons: they're copies of the ones you created for digital buttons, but the circle is fainter and broken in four pieces.

pzmarzly commented 5 years ago

Looks awesome.

It looks like I wrote over every file, but I separated my edits into different commits.

Don't worry, I always review changes by opening each commit separately.

it made it impossible to move diagonally unless you used two fingers to press two buttons

I noticed that too when I was trying to press b1 and b2 on gamepad layout at the same time. But now it should be possible to use dpad in place of b{1,2,3,4}, though someone may want to have multiple dpads in such scenario.

Tell me if you'd like to add support for multiple dpads before I merge this PR.

Also, I made some minor changes to your master in 1d44f2a , please git pull your local copy.

medape commented 5 years ago

I noticed that too when I was trying to press b1 and b2 on gamepad layout at the same time.

Yeah, it seems obvious in retrospect, but I hadn't noticed it with b_.

But now it should be possible to use dpad in place of b{1,2,3,4}, though someone may want to have multiple dpads in such scenario.

I agree with applying the same system for action buttons, but the problem with expecting users to create D-pads for them is that they may prefer different layouts:

.  b1 .  
b2 .  b3 
.  b4 .

b1 .  b2 .  
.  b3 .  b4

b1 b2 b3 b4

b1 b2
b3 b4

and configuring the new D-pad for every possible shape is impossible. Every corner or side that's shared by two or more buttons has the same problem, and it'll be much easier and more satisfying for everyone to punch in each button separately.

Also, users may want some of them to be triggers/analog buttons. (I think the PSP has analog face buttons. While it's probably not a good candidate for emulation, there may be similar consoles, and users should have the option.)

I can rewrite the button code so they'll all share event handlers (and we'll be able to use a D-pad-like system), but for the moment, I think it's for the better not to add support for several true D-pads.

Also, I made some minor changes to your master in 1d44f2a , please git pull your local copy.

So that's why the linter was insisting on "unreachable code". I thought it was just confused about mixing return with break, but it's really pointless.

Thanks. :smile:

EDIT: By the way, I don't know if you noticed, but I removed a feature I had forgotten to document. Joysticks only used to run vibrate(VIBRATION_MILLISECONDS_IN) if they detected a touch start event near the current pointer location.

I figured it was as useless and confusing as VIBRATION_MILLISECONDS_OUT.

rmst / yoke