Applying PreScale on mickeys directly instead of only on the acceleration curve

[systemofapwne]

The PreScale parameter should directly act on the mickeys instead of only on the acceleration curve. Only when this applies, one can truely use the prescaler to switch between different DPI mice and reproduce the same mouse cursor speed.

---

Longer story of "why".

As I am curently writing a leet2yeet converter for deprecating my LEETMOUSE project in favour for YeetMouse, I had a closer look on both code bases.

LEETMOUSE applies a pre-scaler directly on the "mickeys" and then calculates the rate/speed and acceleration from the new "mickeys".
https://github.com/systemofapwne/leetmouse/blob/8919991ecb92f6f7a45390a746d52275281e3247/driver/accel.c#L158-L164

YeetMouse does not transform the "mickeys" but it applies the pre-scaler to the rate/speed and acceleration only.

YeetMouse/driver/accel.c

Lines 221 to 226 in 3ec6e32

	//Calculate velocity (one step before rate, which divides rate by the last frametime)
	speed = FP64_Sqrt(FP64_Add(FP64_Mul(delta_x, delta_x), FP64_Mul(delta_y, delta_y)));
	// Apply Pre-Scale
	if(g_PreScale != FP64_1)
	speed = FP64_Mul(speed, g_PreScale);

This minute difference has the implication, that one cannot easily migrate the same "feel" of lets say a 400 DPI mouse to an 800 DPI mouse by only changing the PreScale parameter. This becomes direcly clear when writing down the math formula of LEET and Yeet:

    # LEET curve: xout = xin*pre_scale*post_scale*   [1 + (pre_scale*sqrt(x²+y²)/ms + offset)*(accel/sensitivity)]
    # Yeet curve: xout = xin*sensitivity*            [1 + (pre_scale*sqrt(x²+y²)/ms + offset)*accel]

While both implementations will properly scale the acceleration part in the [...] bracket, the xout mickeys of the 800 DPI mouse will be twice as much on Yeetmouse, since the xin are never scaled down too. One could compensate by scaling down sensitivity the same amount as PreScale but that defies the purpose of PreScale for helping to migrate between different mice with different DPIs.

[AndyFilter]

Thanks for pointing this out. I always have trouble finding issues like this, as I don't use most of the feature the program has to offer, and my synthetic testing without any feeling is quite crude and has proven to miss major bugs at times. Though I recently started running my tests with mouse moving in both axes simulated through Arduino Micro, but I haven't simulated different DPIs yet.

I ran these tests now with the old and the fixed code, and it seems to fix the issue quite well!

The x axis on the graph above is correct, as thats what the old code was accounting for, but the value of the acceleration is halved for the lower DPI mouse.

Now everything works perfectly!

---

Now I wonder how this parameter should be represented in the GUI? As currently Pre-Scale only scales the x axis (as that's what I thought Pre-Scale does), but now I wonder if it should scale both axes, or perhaps it should have no effect, as it's effect should be negated by the DPI set on the mouse.

YeetMouse/gui/FunctionHelper.cpp

Lines 338 to 340 in 3ec6e32

	return ((params->outCap > 0) ? fminf(val, params->outCap) : val) * params->sens;
	}

One could add the Pre-Scale here, but, again that would just scale the curve up and down, if I understand correctly.

What are your thoughts on this?

---

When testing this PR I also found a couple of issues I must have missed (the point I was making earlier, haha). So I'll fix them shortly after merging this PR.

Thanks for the contribution!

[systemofapwne]

Now I wonder how this parameter should be represented in the GUI? As currently Pre-Scale only scales the x axis (as that's what I thought Pre-Scale does), but now I wonder if it should scale both axes, or perhaps it should have no effect, as it's effect should be negated by the DPI set on the mouse.

There are in principle two ways I can think about representing PreScale:

• Scale the x-axis and have the graph's appear unchanged for different PreScale factors
• Keep the spacing on the x-axis the same but extend/contract the graph for different PreScale factors
  The second option might yield the best user experience, since the graph visually is changing. Scaling the x-axis might be too subtile.

Either way, the y-axis should not scale (the whole behaviour point of this PR). Scaling y-axis is the job of the sensitivity setting ("post scale").