Jump to content

Sekiro: Shadows Die Twice

Just added!
Read more...

Satisfactory

Find a short-term solution for your long-term problems!
Read more...

Golf With Your Friends

Golf with accuracy!
Read more...

Bunker Punks

Sensitivity for this game has to be set in the registry.
Read more...

Quantum League

Added hipfire and zoom sensitivity. Use config file for best accuracy.
Read more...
noaimBoii

Best USA coefficient for Battlefield 1?

Recommended Posts

The coefficient is exactly the same as monitor distance in the calculator. I.e. you choose with the coefficient value where on the monitor you match the sensitivity.

So 1.33 is the same as 75% in 16:9, and means that movement to 75% between the crosshair and the edge of the monitor is matched between scopes and aims. It is coming from 4:3 indeed, where 1.33 is the same as 100%.

What you choose as a coefficient is more a personal preference however, there is no right or wrong.

Share this post


Link to post
Share on other sites

I personally match the co efficient with viewspeed, the variance from different FOV ingame are not noticeable IMO applying it to the USA co efficient system.

Share this post


Link to post
Share on other sites
On ‎14‎/‎06‎/‎2017 at 6:53 AM, fenriquez said:

how would you match the coefficient with viewspeed DNAMTE? i don't fully understand, if you don't mind elaborating :/, Thanks.

First of all select a game to convert to battlefield 1 and enter all your details in the conversion box. Secondly, select battlefield 1 and enter the appropriate details. Convert your hip fire sensitivity via view speed. Take note of your battlefield 1 sensitivity value.

If you then click on the 'aim' tab in the battlefield 1 conversion box and select USA co efficient. (If you scroll down you will see instructions and a basic explanation on how to fill out the required fields. NOTE; sensitivity 1 will be your hip fire calculation you previously worked out. Sensitivity 2 = 1. Multiplier 1 = 1)

Your new USA co efficient should be displayed in the Multiplier 2 box below!

 

The alternative is to scroll through each zoom sensitivity value in the config file and match individually with view speed, which provides a degree of extra accuracy I don't think anyone would notice...

 

PS: I did the alternative option because I have no life... :D

 

 

Share this post


Link to post
Share on other sites

0% makes the most sense. It matches crosshair speed and is scaling your sensitivity directly with the zoom amount.

Example in Overwatch since I don't have bf1 installed currently due to a reinstall of windows (and there's also no test map anyway)

103 hipfire to 51 zoom is 2.636x. This can be shown by placing a screenshot of zoomed on top of a hipfire image and scaling the former down by 2.636x like so:HN5GcL3.jpg

the width and height of the zoomed image are 37.94% of the hipfire image, or 2.636^-1. If you're zoomed in by 2.636x it would make sense that you scale your sensitivity by the same exact factor. And like I said earlier it matches crosshair speed perfectly. As you get farther away from crosshair it gets less accurate (but not by much until you get above 50% screen distance).

Viewspeed is not accurate at all screen distances either though. It uses the average error between your 2d screen and the 3d FOV to give a sensitivity. Key word here is average. It can still only be perfectly accurate at a single screen distance. I suppose its *average* accuracy across all screen distances will be higher. However you're not aiming at the edges of you're screen. You're aiming with the center of your screen. Viewspeed will have worse match accuracy near your crosshair while its accuracy peaks around 70% screen distance.

Matching your ADS to 70% screen distance of hipfire would only be perfectly accurate when doing mouse flicks to enemies on the green circle

fgrxiQs.jpg

For the vast majority of players mouse flicks this large aren't very common. The most common is by far tracking enemies under your crosshair or doing small flicks to enemies near it. It's much better to have accurate matching closer to the crosshair.

Edited by Skwuruhl

Share this post


Link to post
Share on other sites

If you use 45 in OW then use 133% in BF1. It'll be the same match distance of 75%.

 

Alternatively use 70% match distance or coefficient 1.2444... which will be virtually the same as viewspeed. unless you have an fov of like 170 and a zoom fov of 1.

Edited by Skwuruhl

Share this post


Link to post
Share on other sites
On ‎20‎/‎06‎/‎2017 at 9:21 PM, Skwuruhl said:

0% makes the most sense. It matches crosshair speed and is scaling your sensitivity directly with the zoom amount.

Example in Overwatch since I don't have bf1 installed currently due to a reinstall of windows (and there's also no test map anyway)

103 hipfire to 51 zoom is 2.636x. This can be shown by placing a screenshot of zoomed on top of a hipfire image and scaling the former down by 2.636x like so:HN5GcL3.jpg

the width and height of the zoomed image are 37.94% of the hipfire image, or 2.636^-1. If you're zoomed in by 2.636x it would make sense that you scale your sensitivity by the same exact factor. And like I said earlier it matches crosshair speed perfectly. As you get farther away from crosshair it gets less accurate (but not by much until you get above 50% screen distance).

Viewspeed is not accurate at all screen distances either though. It uses the average error between your 2d screen and the 3d FOV to give a sensitivity. Key word here is average. It can still only be perfectly accurate at a single screen distance. I suppose its *average* accuracy across all screen distances will be higher. However you're not aiming at the edges of you're screen. You're aiming with the center of your screen. Viewspeed will have worse match accuracy near your crosshair while its accuracy peaks around 70% screen distance.

Matching your ADS to 70% screen distance of hipfire would only be perfectly accurate when doing mouse flicks to enemies on the green circle

fgrxiQs.jpg

For the vast majority of players mouse flicks this large aren't very common. The most common is by far tracking enemies under your crosshair or doing small flicks to enemies near it. It's much better to have accurate matching closer to the crosshair.

When the earth was flat.

 

PS:

''Viewspeed is not accurate at all screen distances either though. It uses the average error between your 2d screen and the 3d FOV to give a sensitivity. Key word here is average. It can still only be perfectly accurate at a single screen distance. I suppose its *average* accuracy across all screen distances will be higher. However you're not aiming at the edges of you're screen. You're aiming with the center of your screen. Viewspeed will have worse match accuracy near your crosshair while its accuracy peaks around 70% screen distance.

Matching your ADS to 70% screen distance of hipfire would only be perfectly accurate when doing mouse flicks to enemies on the green circle''

WRONG.


This chain maintains the exact same speed regardless of radius. FOV - FOV is simply one radius to another radius.
Bike_Chain_043cb.gif

 

Matching 3D is as simple as matching 2D. Forget comparing viewspeed with Monitor match percent, values may cross, but they are defined by different methods entirely. Viewspeed is never always exactly 70% monitor distance, nor any other. Viewspeed is not defined by a point on your screen.

Yes, you can broadly define viewspeed by a median percentage comparison over a median grouping of FOV, broadly define is where the comparison ends.
rack_pinion.gif

Edited by DNAMTE

Share this post


Link to post
Share on other sites

Except that your monitor actually is flat.

VQReDj0.png

Ignore the green lines for a moment. You're finding the length of your *entire* field of view. Now this is fine and dandy for finding average the error for the entire screen. Thing is that you only aim at stuff in the middle of it. I could personally give a rats ass about the speed of stuff in the corner of my screen. The only thing that is useful for is situational awareness. All the aiming happens in the middle so that's where apparent speed is important.

Consider the green lines, they mark 25% screen distance from the center. Reasonable area to be doing your aiming. The error between these is going to be much lower. An entire magnitude actually, less than 1%. The length of the cord and arc for that 25% is 156.23 and about 156.85 respectively. For all intents and purposes if you match the viewspeed of that area marked in green it will be identical to matching at 25% screen distance.

Hell even if you do 70% screen distance the chord and arc length are 468.7 and about 486.83. Only a difference of less than 4%. And as you can see above 70% distance is a huge circle. Very few people regularly do mouse flicks that large. And especially not to justify hurting the accuracy near crosshairs.

Share this post


Link to post
Share on other sites
58 minutes ago, Skwuruhl said:

Except that your monitor actually is flat.

VQReDj0.png

Ignore the green lines for a moment. You're finding the length of your *entire* field of view. Now this is fine and dandy for finding average the error for the entire screen. Thing is that you only aim at stuff in the middle of it. I could personally give a rats ass about the speed of stuff in the corner of my screen. The only thing that is useful for is situational awareness. All the aiming happens in the middle so that's where apparent speed is important.

Consider the green lines, they mark 25% screen distance from the center. Reasonable area to be doing your aiming. The error between these is going to be much lower. An entire magnitude actually, less than 1%. The length of the cord and arc for that 25% is 156.23 and about 156.85 respectively. For all intents and purposes if you match the viewspeed of that area marked in green it will be identical to matching at 25% screen distance.

Hell even if you do 70% screen distance the chord and arc length are 468.7 and about 486.83. Only a difference of less than 4%. And as you can see above 70% distance is a huge circle. Very few people regularly do mouse flicks that large. And especially not to justify hurting the accuracy near crosshairs.

Because ingame field of view is radial, simply displayed on a flat screen. Simple logic in the above diagram demonstrates why you cannot measure distance from a flat plane and project it perpendicularly to an arc and expect to get any correlative results between varying Fields of View.

Distance is irrelevant. Velocity, time, two ingredients to -masterful- aiming. Distance becomes relative.

 

Share this post


Link to post
Share on other sites

Okay so accidentally stumbled upon a thing: we're making the assumption that the chord can actually represent your screen.

Equations on this page are widely accepted to be true: https://en.wikipedia.org/wiki/Field_of_view_in_video_games

It's how you convert between HOR+, vertical, and horizontal FOVs. Let's convert between 90° HOR+ to vertical. With an aspect ratio of 4:3 the vertical size of the screen is 3/4ths the horizontal size. So in the equation you plug 3/4ths in like so: http://www.wolframalpha.com/input/?i=2*arctan(3%2F4*tan(90°%2F2))*180%2Fpi for a vertical FOV of 73.74 which this website's calculator will tell you.

Now let's do the same but with chords. Find the radius with a horizontal chord of 1920p and 90°: http://www.wolframalpha.com/input/?i=1920%3D2*r*sin(90°%2F2). Vertical chord is 1080p, plug that in with our radius and: http://www.wolframalpha.com/input/?i=1080%3D2*960+sqrt(2)*sin(t%2F2) which is either 313.123° which can obviously be thrown out or 46.8765° which is also wrong. Unless you hope to argue than an image has a different radius throughout, it doesn't work.

Another way to look at it:

3Eup1F3.png

If your hor+ is 90° then 73.74° will take place at the top edge of your screen, period. You assume that the chord represents the phsysical monitor yet this shows that can't be possible. In retrospect I should have made the black chord 1920 but I already made the image and the only thing that matters is the proportions. Fixed

Edited by Skwuruhl

Share this post


Link to post
Share on other sites
On 6/22/2017 at 1:41 AM, DNAMTE said:

''Viewspeed is not accurate at all screen distances either though. It uses the average error between your 2d screen and the 3d FOV to give a sensitivity. Key word here is average. It can still only be perfectly accurate at a single screen distance. I suppose its *average* accuracy across all screen distances will be higher. However you're not aiming at the edges of you're screen. You're aiming with the center of your screen. Viewspeed will have worse match accuracy near your crosshair while its accuracy peaks around 70% screen distance.

Matching your ADS to 70% screen distance of hipfire would only be perfectly accurate when doing mouse flicks to enemies on the green circle''

WRONG.

It's mathematically impossible to match the entire monitor perfectly but ok. Like I don't know what to tell you here. You can never project a 3d image onto a 2d plane without distortion. This distortion makes it impossible to make the entire screen perfectly accurate.

On 6/22/2017 at 1:41 AM, DNAMTE said:

This chain maintains the exact same speed regardless of radius. FOV - FOV is simply one radius to another radius.
Bike_Chain_043cb.gif

Honestly this makes no sense in relation to viewspeed. Let's assume my previous post is "solved" so that you actually can assume the chord is your monitor. The radius for 90° and 40° is 1357.6 and 2806.9 respectively if your chord is 1920. In this case in order to match the chain you would need the 40° gear to rotate at 48.37% of the speed of the 90° gear. Viewspeed says the zoomed sensitivity needs to be 40.84% of hipfire. Obviously 48.37% is way too high so don't even bother using this method, additionally it relies on the monitor being representable by chord which I already brought into question.

On 6/22/2017 at 1:41 AM, DNAMTE said:

Matching 3D is as simple as matching 2D. Forget comparing viewspeed with Monitor match percent, values may cross, but they are defined by different methods entirely. Viewspeed is never always exactly 70% monitor distance, nor any other. Viewspeed is not defined by a point on your screen.

Yes, you can broadly define viewspeed by a median percentage comparison over a median grouping of FOV, broadly define is where the comparison ends.

Literally what you're doing is dividing chord length by arc length and multiplying the result by what 100% match distance would give you. If this is supposed to be perfect for every single spot on the screen this should raises several flags for you. Why 100% horizontal distance instead of vertical. What about diagonal FOV? What's so special about the point that's 100% match distance?

So you can't say "but it doesn't use 100% match distance":

360°/103FOV * 10.16cm * (2560/2940.2224) = 30.9185 cm

In this equation "360°/103FOV * 10.16cm" is 100% match distance as 10.16cm comes from 2560/640*2.54 or the distance to move the cursor across the screen in desktop. Even ignoring that, the FOV you're basing your calculations off of is the still one at the center of the left/right edge of the screen. I.e. 100% screen distance. You can't claim it's perfect for the entire screen but then choose an arbitrary starting point.

Edited by Skwuruhl

Share this post


Link to post
Share on other sites
7 hours ago, Skwuruhl said:

It's mathematically impossible to match the entire monitor perfectly but ok. Like I don't know what to tell you here. You can never project a 3d image onto a 2d plane without distortion. This distortion makes it impossible to make the entire screen perfectly accurate.

Honestly this makes no sense in relation to viewspeed. Let's assume my previous post is "solved" so that you actually can assume the chord is your monitor. The radius for 90° and 40° is 1357.6 and 2806.9 respectively if your chord is 1920. In this case in order to match the chain you would need the 40° gear to rotate at 48.37% of the speed of the 90° gear. Viewspeed says the zoomed sensitivity needs to be 40.84% of hipfire. Obviously 48.37% is way too high so don't even bother using this method, additionally it relies on the monitor being representable by chord which I already brought into question.

Literally what you're doing is dividing chord length by arc length and multiplying the result by what 100% match distance would give you. If this is supposed to be perfect for every single spot on the screen this should raises several flags for you. Why 100% horizontal distance instead of vertical. What about diagonal FOV? What's so special about the point that's 100% match distance?

So you can't say "but it doesn't use 100% match distance":


360°/103FOV * 10.16cm * (2560/2940.2224) = 30.9185 cm

In this equation "360°/103FOV * 10.16cm" is 100% match distance as 10.16cm comes from 2560/640*2.54 or the distance to move the cursor across the screen in desktop. Even ignoring that, the FOV you're basing your calculations off of is the still one at the center of the left/right edge of the screen. I.e. 100% screen distance. You can't claim it's perfect for the entire screen but then choose an arbitrary starting point.

100% is simply Horizontal Resolution / DPI * 2.54 (360 / FOV). The foundation.

As far as cogs and relevance go. they are quite relevant. Nothing is perfect, I agree. One thing is for sure that we now have something that points to a better solution then choose somewhere between 0% and 100% monitor match.

If you want to take cogs as a direct example, doubling the FOV (45 to 90) should result in exactly half the mouse distance to perform a 360, since FOV is an arc, arc is part of a circle...

pulley4.gif

If your wondering what might that magic number be, 75% monitor match (4:3 resolution). Which is why viewspeed was so interesting as it differed ever so slightly, input discrepancy? I'm not convinced. 

Why not just use 75%? You can and it's all close enough to not matter in game.

My nagging issue in using simply 75% monitor match has its own questions. 90fov to 45fov doubles the mouse distance required to perform a 360. Your screen however remains the same size, therefore the zoom must be at least doubled to account for the smaller radius to fill your 'view space'.

How this ultimately changes things I've not tried to calculate and until it can be clarified I'm satisfied in using the difference in arc and chord length to determine the difference in speed. It certainly made matching desktop to 3D programs feel much more natural.

 

Maybe you would like to help?

 

Edited by DNAMTE

Share this post


Link to post
Share on other sites
8 hours ago, Drimzi said:

After looking over it, the pulleys analogy doesn't apply to viewspeed. Like you said, if it did then the rotation speed would be much faster. That doesn't necessarily make it a method to avoid though. You could do the pulley method to construct the rotation speeds for varying fovs, and it would scale properly and not stick close to 70% monitor distance match like viewspeed does. It would go beyond 100% distance. It would make 360, monitor distance, and this method entirely different. You can just work out the circumferences of a given set of FOVs and find the ratio between them, and increase the 360 distance by that ratio to find the new sensitivity.

Base sensitivity here is Viewspeed, 2560x1440 @ 400 CPI, Windows/Desktop to Counter-Strike: Global Offensive. Using the rule to determine the pulley speed based on the size, this is the result from 90 fov hipfire to 40 fov zoomed in with the awp. Used wolfram alpha to get results.


90 FOV Hipfire

distance			= 2560/400 
				= 6.4 inches;

fov				= 2×atan(16/9×3/4 tan(90/2×π/180))×180/π
				= 106.26 degrees;

radians				= 2×atan(16/9×3/4 tan(90/2×π/180))
				= 1.85459 radians;

arc				= 6.4 + 6.4×(R - 2 sin(R/2))/(2 sin(R/2)) where R = 2×atan(16/9×3/4 tan(90/2×π/180))
				= 7.41836 inches;

circumference			= 360/(R×180/π) × A where R = 2×atan(16/9×3/4 tan(90/2×π/180)), A = 6.4 + 6.4×(R - 2 sin(R/2))/(2 sin(R/2))
				= 25.1327 inches;
                
custom 360 distance		= (4 π z sin(x/2))/x^2 where z = 2560/400, x = 2×atan(16/9×3/4 tan(90/2×π/180))
				= 18.7061 inches;

40 FOV AWP

fov				= 2×atan(16/9×3/4 tan(40/2×π/180))×180/π
				= 51.774 degrees;

radians				= 2×atan(16/9×3/4 tan(90/2×π/180))
				= 0.903627 radians;

arc				= 6.4 + 6.4×(R - 2 sin(R/2))/(2 sin(R/2)) where R = 2×atan(16/9×3/4 tan(40/2×π/180))
				= 6.62304 inches;

circumference			= 360/(R×180/π) × A where R = 2×atan(16/9×3/4 tan(40/2×π/180)), A = 6.4 + 6.4×(R - 2 sin(R/2))/(2 sin(R/2))
				= 46.052 inches;
                
ratio				= 46.052 / 25.1327
				= 1.832354;
                
360 distance			= 18.7061 × (46.052 / 25.1327)
				= 34.2762 inches;

 

6 hours ago, Drimzi said:

You could probably just straight up use the circumference as the 360 distance for an FOV as well, it's all derived from a given resolution and DPI. That would be the 2D to 3D conversion. If you wanted to ignore your desktop sensitivity and use your own game sensitivity, then you use the sensitivity ratio between FOVs, like I did above where I used my own sensitivity of 18.7061 inch.

Here's the full formula to find the circumference (inches) for an FOV, using your Resolution, DPI, WPS, etc.

w = resolution width

h = resolution height

f = 4:3 base horizontal fov value

d = mouse dpi * windows pointer speed multiplier

The end result is the circumference in inches. Multiply by 2.54 for cm.

 

edit: actually I think there's an error in there somewhere. 45 fov should be exactly twice as big as 90 fov.

 

360° turn distance for an fov of 45° should be twice as big as that for a 90° fov if you had a screen that had the correct curve. Since 99% of people use a flat screen the distance won't be double unless you match at 100% screen distance. "Cog method" or whatever you want to call it (and also viewspeed) still relies on your monitor being representable by a chord. This doesn't seem to be mathmatically correct from what I can tell.

Ignoring that, I can't tell where you're getting 2 sin(R/2). If you're trying to match "chain speed" then you just take the ratio of the radii calculated from chord = 2 r sin(fov/2) like here http://www.wolframalpha.com/input/?i=h+%3D+103,+z+%3D+51,+j+%3D+1%2F2+c+csc((h+π)%2F360),+x+%3D+1%2F2+c+csc((π+z)%2F360),+j%2Fx%3D

Regardless the chord thing seems flawed so by extension so is this.

On 6/22/2017 at 11:22 PM, DNAMTE said:

100% is simply Horizontal Resolution / DPI * 2.54 (360 / FOV). The foundation.

As far as cogs and relevance go. they are quite relevant. Nothing is perfect, I agree. One thing is for sure that we now have something that points to a better solution then choose somewhere between 0% and 100% monitor match.

If you want to take cogs as a direct example, doubling the FOV (45 to 90) should result in exactly half the mouse distance to perform a 360, since FOV is an arc, arc is part of a circle...

pulley4.gif

If your wondering what might that magic number be, 75% monitor match (4:3 resolution). Which is why viewspeed was so interesting as it differed ever so slightly, input discrepancy? I'm not convinced. 

Why not just use 75%? You can and it's all close enough to not matter in game.

My nagging issue in using simply 75% monitor match has its own questions. 90fov to 45fov doubles the mouse distance required to perform a 360. Your screen however remains the same size, therefore the zoom must be at least doubled to account for the smaller radius to fill your 'view space'.

How this ultimately changes things I've not tried to calculate and until it can be clarified I'm satisfied in using the difference in arc and chord length to determine the difference in speed. It certainly made matching desktop to 3D programs feel much more natural.

 

Maybe you would like to help?

My point was that there's no objective reason to be using horizontal fov/resolution instead of vertical or even diagonal.

I would strongly disagree that viewspeed is "better" than matching a screen distance. In fact I even dislike the name because it's misleading. You can only match the "speed" at a single circle on the monitor. That's just how projecting a 3d image onto a 2d plane works. You can get a pretty close speed on the rest of the monitor, but it gets farther off the farther you are from the circle. It's why I personally like to have the speed matched at my crosshair.

Like I already said in this post going from 45° to 90° should double your sensitivity if and only if your monitor is curved to match. You lose your ability to accurately do 45°/90°=50% when you start using a 2d plane for your 3d image. Going from 90° to 45° fov on a flat screen isn't 2x zoom. With my image previous in this thread I showed that for flat screens the zoom amount is tan(90°/2)/tan(45°/2)=2.414

There's nothing truely special about 75% either. It feels pretty decent for most people sure, but originally it was just 100% match distance for source engine's fov method. The devs just did 40/90 for their 4:3 resolution game. Other games like battlefield just copied this because it's what people are used to. In fact it's literally one of the reasons listed by one of the designers of battlefield's system:

"that's what CS:GO used and compatability is awesome" - https://battlelog.battlefield.com/bf4/forum/threadview/2979150494051524581/

note: I'm not really sure what you were trying to say with 75% so I kinda just guessed?

 

 

Share this post


Link to post
Share on other sites
3 hours ago, Skwuruhl said:

360° turn distance for an fov of 45° should be twice as big as that for a 90° fov if you had a screen that had the correct curve. Since 99% of people use a flat screen the distance won't be double unless you match at 100% screen distance. "Cog method" or whatever you want to call it (and also viewspeed) still relies on your monitor being representable by a chord. This doesn't seem to be mathmatically correct from what I can tell.

Ignoring that, I can't tell where you're getting 2 sin(R/2). If you're trying to match "chain speed" then you just take the ratio of the radii calculated from chord = 2 r sin(fov/2) like here http://www.wolframalpha.com/input/?i=h+%3D+103,+z+%3D+51,+j+%3D+1%2F2+c+csc((h+π)%2F360),+x+%3D+1%2F2+c+csc((π+z)%2F360),+j%2Fx%3D

Regardless the chord thing seems flawed so by extension so is this.

My point was that there's no objective reason to be using horizontal fov/resolution instead of vertical or even diagonal.

I would strongly disagree that viewspeed is "better" than matching a screen distance. In fact I even dislike the name because it's misleading. You can only match the "speed" at a single circle on the monitor. That's just how projecting a 3d image onto a 2d plane works. You can get a pretty close speed on the rest of the monitor, but it gets farther off the farther you are from the circle. It's why I personally like to have the speed matched at my crosshair.

Like I already said in this post going from 45° to 90° should double your sensitivity if and only if your monitor is curved to match. You lose your ability to accurately do 45°/90°=50% when you start using a 2d plane for your 3d image. Going from 90° to 45° fov on a flat screen isn't 2x zoom. With my image previous in this thread I showed that for flat screens the zoom amount is tan(90°/2)/tan(45°/2)=2.414

There's nothing truely special about 75% either. It feels pretty decent for most people sure, but originally it was just 100% match distance for source engine's fov method. The devs just did 40/90 for their 4:3 resolution game. Other games like battlefield just copied this because it's what people are used to. In fact it's literally one of the reasons listed by one of the designers of battlefield's system:

"that's what CS:GO used and compatability is awesome" - https://battlelog.battlefield.com/bf4/forum/threadview/2979150494051524581/

note: I'm not really sure what you were trying to say with 75% so I kinda just guessed?

 

 

The shape of your screen is irrelevant. Both things we are comparing use the same screen. FOV is part of an arc, part of a complete circumference... When comparing pulley speed we need two pulleys or two circles, thus disregarding your monitor all we need is two FOV to compare. Your monitor for this comparison can be shaped like a pyramid, it does not matter.

As for 75%, if we disregard zoom and simply compare FOV and the consequent circumference, then 75% monitor match is the exact percentage where all FOV will exactly match circumferential speed (4:3), eg; 50FOV to 100FOV matched at 75% Monitor Match will have the exact same circumferential speed. Just like this diagram. It certainly wasn't just a stab in the dark to settle on 75%, BF1 did follow suit by 'feel', I agree.

pulley4.gif

Obviously there's more to consider which I outlined in my previous post.

Share this post


Link to post
Share on other sites

I worked a lot on this for the testing when DICE dev Julian Manolov first implemented DarkEthereal's ideas during BF4 CTE.

To cut a long story short, Having a coefficient of 0% (i.e viewspeed under "the centre of crosshair" match) makes "effective" sensitivity feel slower as zoom increases / FOV decreases with the different scopes in the game. This is a pretty objective phenomenon and every person who was testing it reported the same results. 

The idea of USA in the first place was to create a system which could remove the need for random turn-rate multipliers, which were never going to work for everyone because they didn't/don't take into account user base FOV selection, even if the different ADS FOV multipliers were reasonably and accurately modelled in the first place (which they weren't).

A setting of matching 4:3 distance (i.e 133%) made the best compromise across ALL the zoom levels in BF4. which is why it is the default.  It was not simply to "match CS:GO". There has been way too much emphasis put on that throw away remark from Dark.

If you're not interested in matching ALL zoom levels as close as possible (for example, if you only ever rock iron sights) then having a closer to screen center coefficient might work out better, and of course, the less you change FOV with a low-zoom scope the less the coeffecient matters anyway. But as been already mentioned, it is literally impossible to match a sensitivity across ALL the screen space of a 3D game, due to the 3D/2D distortion factor. 

BF1 doesn't have as high zoom levels as BF4 with sniper scopes, and critically, there is no "blanking of the edges" outside the scopes. That is to say, your brain still gets viewspeed information from your peripheral view in BF1 with snipers (albeit blurry), whereas it doesn't in BF4. What you find  when your peripheral view is blanked, off, and you can only see the "centre portion" of the FOV (which looks "flatter" and is the slower moving portion of the screen as you turn) is this creates a sensation of lowered "effective sensitivity". Which is one of the reasons why BF4 needed a slightly faster overall setting of 133% to be the default, cause we had to account for 20x zoom scopes with blanked out edges.

When I play BF1, since I only use zoom levels up to 4x zoom, and no scope blanks peripheral, I play at a coefficient of 88.8888%. In other words, exactly the halfway point between the centre of my screen, and the horizontal edge on a 16:9 display. This is also exactly the centre of any "FOV curve" also, since the 3D/2D conversion bends the image of course. Aiming to anything outside that point is slightly slower, aiming to anything inside that point is slightly faster compared to hipfire FOV.

One of the problems with this whole thing is the industry standard terms for defining what is "sensitivity" as far as muscle memory / aiming ability goes. There is a huge fixation in FPS gaming of matching 360 distances, but that is actually just "turn-rate" - an objective value, whereas "sensitivity" has to be subjective - the key is in the word - your SENSation of movement. Effective sensitivity - which is what matters when we're talking about aiming and muscle memory, is a combination of a turn rate across a monitor distance / FOV. I hear people all the time using this website or their tape measure  to match 360 distances between games that don't even have the option to replicate the same FOV they use, and that is completely pointless, since a different FOV at the same turn-rate, changes effective sensitivity (i.e aiming muscle memory) which was the whole reason USA or aiming multipliers are needed in the first place.

Share this post


Link to post
Share on other sites

I've been thinking too much again. IMO the reason 0% feels too slow is because its simply relative to sensitivity, meaning sensitivity should not be matched by correlating zoom, rather zoom is a product of correlating sensitivity.

In this diagram putting games aside, we can say the small 45' Arc circumference requires double the input (mouse movement) to match the circumferential speed of 125'. We can also see that the 'view space' at 45' must be multiplied by 4.64 to fill the 'view space'.

Maintaining the 'circumferential speed' relationship ultimately ensures your radial view maintains the same speed?

Capture.png

 

Edited by DNAMTE

Share this post


Link to post
Share on other sites

Hi drimzi, I am trying to understand the zoom ratio in relation to games. Looking at your formula its basing the coefficient FOV on 106.26 fov (90 fov 4:3). So having 106.26 as a hipfire fov, and your aim down sights FOV scaled based on the zoom ratio coefficient, it should give the same radial speed between both corresponding arcs (your hipfire and aim-down sight fov)???? I apologize my math is not too strong, I just want to understand your thinking here. Are you saying this method might be more optimal than your original viewspeed method??

Share this post


Link to post
Share on other sites

3Eup1F3.png

Nobody has addressed this potential issue with using chord as "resolution" or whatever else

 

Also in this example:

Capture.png

If you wanted to make a chain or whatever spin between these two you'd use the ratio of the radii. Assuming when you say "circumferential speed" you mean circumference * revolutions per <time period>. It happens so that this is also the ratio of the circumferences.

Edited by Skwuruhl

Share this post


Link to post
Share on other sites
23 hours ago, Drimzi said:

I think I made the formula for what you are picturing. I have been trying all sorts to find the perfect coefficient but one coefficient can not be used for all FOVs. It just does not result in the same speed. The current viewspeed implementation does not scale as much as it needs to in order to match the speed. The coefficient is still pretty static across the FOV range. The perfect solution shouldn't match at a single point on the monitor if the FOV is different. You need a unique coefficient for every zoom level. Here is what I have come up with so far and I think it works well from the very brief testing I have done.

 

Heres something to consider. Take this example:

Capture.png

 

Putting alternate theory aside for a second and lets look at zoom factor. Essentially we are going to multiply the 45' 'viewspace' by 4.64, thereby filling up the 125' viewspace'. Now we have two arcs with equal chord length, however the expanded 45' viewspace does not share the same geometry as the 125' viewspace. The 125' arc is 1.1966 times longer.

Point being even when we have a FOV over two and a half times larger, the actual arc length differential can be minimal.

Ultimately even before we figure out exactly how far the apple drops from the tree, ALL FOV are scaled in some correlated way to fill the same size screen.

 

EDIT. WIP... thought I'd add this diagram here if anyone would find it useful. The numbers between dimensions are ratios.

Capture2.png

 

 

Edited by DNAMTE

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...