Viewspeed v2

[iBerggman]

14 hours ago, Drimzi said:

Yeah switched from diagonal 4:3 to horizontal 16:9.

The actual fov scaling formula remains the same and is finished.

The only thing that's left is the 2D to 3D conversion. Since we are only using the 2D sensitivity as the starting point, you can make the starting point whatever sensitivity you want. If you want 50 cm 360 in CSGO for example, you just need to change π r to 50 and then delete the variable declarations for the desktop sensitivity like h=...; m=...; r=...; so it will be 50 csc(x/2)/sqrt(2), the output will be in cm since the units have changed, but you can always just do 50/2.54 to change the units to inches again.

Okay, thanks! I'll play some pubg today so I'll test out the 16:9 conversion first, I kind of like the idea of matching desktop - game. Not sure if it helps at all with building muscle memory for aiming but it does feel easier to go between 2D and 3D, especially in games where you both aim and use the cursor. 

[massivelivefun]

Um, I've just begun to read the whole thread, but I just wanted to throw this question out there:

- Can a user have a distinct 360 measurement for their sensitivity, and then still implement this iteration of viewspeed to "pass" on their muscle memory to other games?
I.E. If a user is hypothetically insane with a exact 20.00 inch 360 on csgo, or whatever, can they still maintain the aforementioned 360 using this formula, and then "pass" on their muscle memory to other games.

The inputs for this formula look like they are just dependent on cpi, fov, and vertical pixel screen space.

I understand that the aim of this Viewspeed formula is that muscle memory is at the forefront. That, no matter what fov the game may be at you should be hitting nasty flicks. However, if this formula basically gives a predetermined distance based on three distinct things, then it sounds like certain distances may never be outputted by this formula at all.

That, and if an individual wishes to use this formula they may have to readjust their muscle memory.

Edited August 14, 2017 by massivelivefun

[Drimzi]

Edited January 28, 2018 by Drimzi

[massivelivefun]

Okay, so for instance, here is an example of csgo hipfire sens at 3 @ 400 (13.6364 inch / 34.6364 cm 360):

h=1080;

m=400;

r=(h×16/9)/m;

d=34.6364;

x=106.26;

θ=2 atan(tan((π (2 atan(3/4 tan((π x)/360))×180/π))/360));

π r d ( csc(θ/2)/sqrt(2);

= 34.6365 cm

http://www.wolframalpha.com/input/?i=x%3D106.26;+θ%3D2+atan(tan((π+(2+atan(3%2F4+tan((π+x)%2F360))×180%2Fπ))%2F360));+34.6364+csc(θ%2F2)%2Fsqrt(2)

The resultant almost returns the same distance, but wolfram alpha's approximations created discrepancies unfortunately.
Probably safe to assume that the result is just 34.6364, especially when the range to get this 360 in the calculator is from 2.999981 to 3.000003. 3 being closer to the range's ceiling explains the round up.

 

Then to match the hipfire sens to the first awp zoom, we need to only change x to the horizontal fov of the first zoom and keep the rest, which is this:

d=34.6364;

x=51.77;

θ=2 atan(tan((π (2 atan(3/4 tan((π x)/360))×180/π))/360));

34.6364 csc(θ/2)/sqrt(2);

= 71.6144 cm

http://www.wolframalpha.com/input/?i=x%3D51.77;+θ%3D2+atan(tan((π+(2+atan(3%2F4+tan((π+x)%2F360))×180%2Fπ))%2F360));+34.6364+csc(θ%2F2)%2Fsqrt(2)

Afterwards we use the calculator to find the in-game sensitivity from the distance for both of the distances above.

 

Is this the correct approach?

EDIT: Holy fuck this feels mint af. You guys are geniuses, like goddamn this is insane.

Edited August 14, 2017 by massivelivefun

[Drimzi]

Edited January 28, 2018 by Drimzi

[Bryjoe]

So, I understand the idea behind this, but since so many game use the 75% 4:3 Aspect Ratio, wouldn't it be easier on most gamers to use the existing viewspeed calculation? To apply this to a game like Battlefield, or to games with multiple view sensitivities, you would need to calculate it for each zoom. Systems like USA make this process so much easier in Battlefield. 

I just wonder if it is worth the trouble.

[KandiVan]

Hi I went to work in the boonies for two weeks, so diagonal is what were going with for now?

[Drimzi]

Edited January 28, 2018 by Drimzi

[KandiVan]

8 minutes ago, Drimzi said:

Na back to horizontal. Diagonal was great for Monitor match only.

And thats whats in the initial post right now? Am I calculating multiple FOV's off of that or am i just doing hipfire and then matching at 100% MM?

[Drimzi]

Edited January 28, 2018 by Drimzi

[KandiVan]

1 minute ago, Drimzi said:

No what is in the original post is the new formula, it generates the 360 value for any fov based off the 90 degree sensitivity, which you can explicitly set or you can just put in your desktop sensitivity. This formula is based off the ratio in the radial plane and the ratio in the 2d plane. Since it is compared against 90 horizontal, it is important to use the horizontal fov. It is entirely different to monitor match, which is pretty much just a measurement with linear scaling, since it is linear using vertical, horizontal, or diagonal doesn't affect the way it scales, it just changes the overall value. The diagonal monitor match was actually fairly close to this when using a 4:3 clamped aspect ratio for fov and desktop. Let's just say monitor match was a very rough estimate.

By horizontal FOV, is Actual HFOV fine or do i need to use 4:3 hFOV?

[Drimzi]

Edited January 28, 2018 by Drimzi

[massivelivefun]

On 8/14/2017 at 6:08 AM, Drimzi said:

Just use the 4:3 fov input, since that is what csgo uses:

 

hipfire: x=90; θ=2 atan(tan((π x)/360));

awp: x=40; θ=2 atan(tan((π x)/360));

Honestly though, why 40 for the config fov for awps? Where did you get that number from? Just curious, is all.

And a followup question, I know that csgo uses 4:3 base, but like isn't it more convenient just to look up the res base of a game's fov through the calculator?

Especially when some fovs are hard to figure out in the config format, i.e. your "40" for awps.

[Drimzi]

Edited January 28, 2018 by Drimzi

[massivelivefun]

13 hours ago, Drimzi said:

If you don't know the fov of the game, just check the calculator:

• If it is resolution based, then use the resolution based formula and enter in the actual hfov value.
• If it is 4:3 based, change the resolution in the calculator to 4x3, copy the actual hfov value, and enter it into the 4:3 based formula.
• If it is vertical, copy the vertical fov value from the calculator and use the vertical based formula.

Thank you, for this tidbit ^^^. This is extremely important and I think you should add this to your master post of this thread as soon as possible.

I just have one more question though. How would you go about matching the viewspeed between two games that use different fov handling? For instance, Csgo is 4:3 based while battlefield is vertical degrees based. Is it impossible to match them together?

Or is it that when your formulas convert to 4:3 hfov it is meant to tackle this problem entirely?

Edited August 16, 2017 by massivelivefun

[Drimzi]

Edited January 28, 2018 by Drimzi

[Kilroy]

Hey, since csgo zoom ratio stays the same no matter what sens you're using, could you tell me what it is, just so I can know whether or not I did this formula right?

Is it....1.088302?

[Drimzi]

Edited January 28, 2018 by Drimzi

[Bryjoe]

On 8/17/2017 at 0:36 AM, Kilroy said:

Hey, since csgo zoom ratio stays the same no matter what sens you're using, could you tell me what it is, just so I can know whether or not I did this formula right?

Is it....1.088302?

I guess, I still don't understand how this is a superior implementation to how viewspeed currently works. Is it based off a 100% calculation now? Wouldn't that feel vastly different compared to 75%?

 

And more importantly, when will this be an option in the calculator so we don't have to calculate the 360 distance for each game that we play.

Edited August 21, 2017 by Bryan Redding

[Drimzi]

Edited January 28, 2018 by Drimzi

[Bryjoe]

50 minutes ago, Drimzi said:

It's not based on 100%. It's based on the chord and apothem ratios between two fovs, one being 90 degrees as a constant, which has the desktop length as the chord. The result is dynamic, within the view it's going to be faster at a lower fov due to less distortion and slower at high fovs due to more distortion. If you add a multiplier comparing chord and arc lengths, which is what viewspeed does, it will remove this distortion compensation and end up as 100% monitor match (at 4:3 portion of screen), which will be the desktop length as a constant chord length for every fov, which is what viewspeed was suppose to do but failed at because it is already using 100% (resolution based) as the starting point.

Ok, well any time table on when this will be implemented into the base version of the calculator? Does it really feel vastly different than viewspeed? Viewspeed feels pretty good, for instance in easy terms, I use 41.6 CM/ 360 on CSGO on a 1440p, 27 inch monitor 800 dpi.

What is the conversion for battlefield at it's default FOV of 55 Vertical?

[DPI Wizard]

1 minute ago, Bryan Redding said:

Ok, well any time table on when this will be implemented into the base version of the calculator?

Not sure when it will be done, but I'm working on it.

[KandiVan]

3 minutes ago, Bryan Redding said:

Ok, well any time table on when this will be implemented into the base version of the calculator? Does it really feel vastly different than viewspeed? Viewspeed feels pretty good, for instance in easy terms, I use 41.6 CM/ 360 on CSGO on a 1440p, 27 inch monitor 800 dpi.

What is the conversion for battlefield at it's default FOV of 55 Vertical?

Feels much better than old viewspeed calculator, at least at hipfire level. Headshot flicks are much more consistent with the new formula. Still cant justify switching my ADS to viewspeed because I feel that low ADS still trumps it in terms of consistency, as much as I wish I could. However, thats only because my main game is H1 and two tapping is so important (first shot is always a headshot, but maintaining that second shot consistency seems difficult for some god forsaken reason, most likely due to the extreme distances). For other FPS like CS/Battlefield/Quake etc I would 100% go full viewspeed. Regardless, use the new formula, its better than the old one.

[Bryjoe]

13 minutes ago, KandiVan said:

Feels much better than old viewspeed calculator, at least at hipfire level. Headshot flicks are much more consistent with the new formula. Still cant justify switching my ADS to viewspeed because I feel that low ADS still trumps it in terms of consistency, as much as I wish I could. However, thats only because my main game is H1 and two tapping is so important (first shot is always a headshot, but maintaining that second shot consistency seems difficult for some god forsaken reason, most likely due to the extreme distances). For other FPS like CS/Battlefield/Quake etc I would 100% go full viewspeed. Regardless, use the new formula, its better than the old one.

I still don't quite understand how to implement it. Like I know my 360 distance in CSGO, this formula is supposed to give me a new one? Once I get this new 360 distance I should use that as 360 distance for every game?

I don't understand the formula, I know my 360 distance in CSGO, why do I need to calculate a new one? If I know my 360 distance in CSGO and don't want to change it, how do I convert it to the new viewspeed calculation?

Edited August 21, 2017 by Bryan Redding

[KandiVan]

34 minutes ago, Bryan Redding said:

I still don't quite understand how to implement it. Like I know my 360 distance in CSGO, this formula is supposed to give me a new one? Once I get this new 360 distance I should use that as 360 distance for every game?

I don't understand the formula, I know my 360 distance in CSGO, why do I need to calculate a new one? If I know my 360 distance in CSGO and don't want to change it, how do I convert it to the new viewspeed calculation?

The formula is matching your windows pointer speed in 2D to your 3D sensitivities in game. You cant convert from in game right now unless Drimzi wants to redo the formula.