Sensitivity Y clarification

[vrnvorona]

Currently I don't entirely understand whether Y is ratio relative to X (seems like it) or separate Y sens not related to X.

From tests it seems like ratio, but it draws graph unrelated to X it seems - at least "Active mode Y" is. For example if I double X but keep Y, X graph is "above" Y, but Y also becomes faster. Is it graph bug?

Thanks in advance. Asking this just so I can find settings in Raw Accel similar to my current YeetMouse.

Also just FYI - lookup table format is not compatible with Raw Accel. Not sure if it's possible/worthwile, but just information.

[AndyFilter]

Hey, yea, it seems like the Y acceleration is applied (possibly) incorrectly on the driver side:

YeetMouse/driver/accel.c

Lines 286 to 287 in 783f8f3

	speed = FP64_Mul(speed, g_Sensitivity);
	FP_LONG speed_Y = FP64_Mul(speed, g_SensitivityY);

speed_y uses speed already multiplied by the X acceleration in it's calculations.

This doesn't seem to be the case on the GUI side (where the speed it divided by sens_x to get raw speed (as it was multiplied earlier) and then multiplied by sens_y):

YeetMouse/gui/FunctionHelper.cpp

Lines 385 to 386 in 783f8f3

	if (params->use_anisotropy)
	values_y[i] = val / params->sens * params->sensY;

(it's not very clean, I know)

Is it graph bug?

It's either a graph bug, or a driver bug. I don't know which behaviour is expected, as I don't use anisotropy, but I presume that the sensitivities should not be relative, right?

Also just FYI - lookup table format is not compatible with Raw Accel. Not sure if it's possible/worthwile, but just information.

Is it not? I thought they also use "x1,y1;x2,y2...". The only difference is that YeetMouse only supports applying LUT as sensitivity.

[vrnvorona]

It's either a graph bug, or a driver bug. I don't know which behaviour is expected, as I don't use anisotropy, but I presume that the sensitivities should not be relative, right?

I am not 100% sure for anisotropy, but in RawAccel there is relative Y/X ratio setting. For anisotropy there is image in Guide:

Screenshot

From it it seems that it's relative and also possible to control both horizontal and vertical parts of curve.
But for my usecase I just do 1.2 Y/X for easier vertical aiming and curve is 1:1. So for your question - personally I expect it to be relative to X, as it is now (thus making it a graph bug). Since I am seemingly first to bring this to attention, it's likely that people are happy with it as is.

Is it not? I thought they also use "x1,y1;x2,y2...". The only difference is that YeetMouse only supports applying LUT as sensitivity.

Yeah, I've noticed tooltip explanation. "Issue" (minor one) is that exported list uses semi-colons always (so x1;y1;x2;y2). Raw accel doesn't accept it and requires strict x1,y1;x2,y2 format.

Maybe it's not export issue but how I got to this table - I've exported custom curve and it seems to converted into lookup table. But even if I change format manually, exported file/text is still using semicolons for both x-y and point-point separator.

PS: as a matter of fact, custom curve feature was incredibly useful for me to file good "smoother jump" curve and I was able to get good result in 30 minutes of testing in game, while in RawAccel I couldn't even replicate it yet in same time and that's how I found semi-colon "issue".

[AndyFilter]

I am not 100% sure for anisotropy, but in RawAccel there is relative Y/X ratio setting

Alright, that's fair. I've looked around and it seems that X/Y ratio is usually relative. So I'll edit the graph code. Now the Y curve should be moving when changing the base (X) sensitivity too.

Raw accel doesn't accept it and requires strict x1,y1;x2,y2 format

Oh, that's interesting, I only accept interchanging commas and semicolons on the GUI side, the driver needs to have just semicolons. But it's an easy change.

PS: as a matter of fact, custom curve feature was incredibly useful for me to file good "smoother jump" curve and I was able to get good result in 30 minutes of testing in game, while in RawAccel I couldn't even replicate it yet in same time and that's how I found semi-colon "issue".

I'm happy to hear that Custom Curve is useful, a lot of work was poured into this feature.

I've implemented the patches and pushed the changes to the feature/anisotropy branch, let me know if everything works fine now.

[vrnvorona]

Graphs and export looks fine to me, thanks!
I will test import into RawAccel tomorrow.

[vrnvorona]

Tested today on Linux, had to revert - for some reason acceleration wasn't behaving as expected. Later will double-check on identical settings, maybe there were conflicts or issues on my side.

UPD: everything is fine, with saved config and reinstall it works the same but graph is correct.

Two things I've also noticed:

1. graph shops at 150 counts/s, so when using high dpi and low multiplier most of the curve is invisible.
2. Saving custom curve saves just lookup table and with reinstall and stuff the curve itself is lost, so if I'd want to tune it later i'd have to write down four custom curve points manually to re-enter them. Just fyi.

[AndyFilter]

Ok, I'm glad everything works as expected now.

graph shops at 150 counts/s, so when using high dpi and low multiplier most of the curve is invisible.

Yea, I'm aware of this. But I always thought that the range of 150 is way more than enough (RawAccel usually goes up to like 80), as it's practically impossible to move the mouse that fast. But now You gave me an idea to perhaps scale the range by the pre-scale parameter so that always the same part of the curve is visible. What do You think of this approach?
Something like this:

Screencast.from.2025-10-19.13-24-26.webm

Saving custom curve saves just lookup table and with reinstall and stuff the curve itself is lost, so if I'd want to tune it later i'd have to write down four custom curve points manually to re-enter them. Just fyi.

Saving Custom Curve points is implemented on the Custom Curve branch, I'm just waiting for the person that created the issue about it to make sure it works (#38).

[vrnvorona]

Yea, I'm aware of this. But I always thought that the range of 150 is way more than enough (RawAccel usually goes up to like 80), as it's practically impossible to move the mouse that fast. But now You gave me an idea to perhaps scale the range by the pre-scale parameter so that always the same part of the curve is visible. What do You think of this approach? Something like this:

Screencast.from.2025-10-19.13-24-26.webm

Looks good to me. Since DPI is basically* multiplier for counts, then it doesn't really matter if count is high or low as same speed will produce more or less counts based on DPI and we can see whole curve just fine if we need to.
From google pictures i was able to see some rawaccel screenshots with high counts as well, but idk how and what determines it in their software.

Saving Custom Curve points is implemented on the Custom Curve branch, I'm just waiting for the person that created the issue about it to make sure it works (#38).

Great!

EDT: On this note, if pre-scale is 1 for 800 DPI, maybe it could be better to use slider as DPI and calculate pre-scale instead of using multiplier? Maybe it could be more obvious to user that they need to enter their DPI and be fine. But that's just idea.

[AndyFilter]

EDT: On this note, if pre-scale is 1 for 800 DPI, maybe it could be better to use slider as DPI and calculate pre-scale instead of using multiplier? Maybe it could be more obvious to user that they need to enter their DPI and be fine. But that's just idea.

I feel like this parameter is a bit more than just DPI matching. It certainly can be used that way and most often probably is, but it can be used to whatever one could desire. It simply denotes a pre scaling parameter. The use of it is described in the tooltip and I think that's enough.
Also I think some people use acceleration with DPI not equal to 800 and don't have this parameter set, and if it was named "DPI" it would kind of suggest that one should put their DPI in there (for whatever reason it may be needed) - but this is just from a small UX standpoint.
I could perhaps add a note to the tooltip that for example says "Configured for N DPI", where N is the DPI calculated from the pre-scale parameter.

[vrnvorona]

Okay, it's fair. Tooltip would be cool idea, but value then should be as is.
Also it's really great feature because after migrating my LUT to RawAccel I wasn't able to make it adjust to increase in DPI (RawAccel doesn't have this type of scaling) and it was too fast, so I probably will have to tune curve itself or not use curve on Windows.

[AndyFilter]

Hey, I was implementing the PreScale graph scaling, and realised some unforeseen consequences of pre-scaling the graph.

It's easiest to see on the Custom Curve or LUT. When PreScale is set to something different than 1, point coordinates don't match the graph (that's why PreScale scaling was disabled for the CustomCurve mode on the graph). But the same goes for all the other modes with parameters like Midpoint. From what I understand the solution is to either not apply PreScale to the graph, or have all the parameters that base on the X axis be incorrect, and I think the first option is better for the UX.

I can still extend the range of the graph when PreScale is applied, it'll look something like this:

Screencast.from.2025-10-26.09-19-41.webm

[vrnvorona]

And how it's handled internally for actual curve (not graph)? Pre-scale is applied after curve calculation so point coords are the same, or...?
Because for me at least it seems to work, though I think I had to adjust X coords to correct for graph being more stretched after pre-scale. Maybe we just have to update all X values by pre-scale factor, or it's not that simple?

[AndyFilter]

Pre-Scale is applied before anything. So for example if the mouse speed is 10, and PreScale is 0.5, then the actual acceleration function will get the speed of 5 (simply $f(s_{peed} \cdot P_{reScale})$). In other words it shifts the curve to the left or to the right by a given multiplier.

The issue is that when the user has Midpoint set to (for example) 8, then with PreScale set to 2, it would actually "engage" at 4 counts/s. Even though the Midpoint is still set to 8.

PreScale = 1	PreScale = 2

Maybe we just have to update all X values by pre-scale factor, or it's not that simple?

This, I'm afraid, would be very troublesome to the user. Because it would change all the parameters that "use" the X axis (not to mention parameters from something like Motivity mode, which kind of "use" the X, but also the Y axis) when sliding the PreScale parameter around. I think it would confuse users when some (random) values would start changing when they weren't modifying them.
Different approach is to divide all these X-related values by PreScale, at export, but then you'll end up with a different curve than was shown to you on the graph.

But, at the end, I think this is just how PreScale works and everyone who's using it is aware of that. The x values simply will not match.

[vrnvorona]

Well okay then, seems like scaling is not ideal. Maybe just add setting to set max seen X so that there is no need to calculate scaling? Or just increase it to some large value and be with it, zoom still works.

[AndyFilter]

This issue isn't really about zooming or the X axis. I just noticed this problem when playing with prescale for the zooming feature. But I think that if no one brought this "issue" up so far, it means that's it's not an issue and everyone using prescale is aware of how it works.
I'll merge the changes as is then. So like this: #62 (comment) (+ changed prescale tooltip). And the Custom Curve will still ignore the PreScale on the GUI side to preserve visual integrity.