Widescreen Gaming Forum

If I want to further increase the FOV value beyond what Jackfuste has done, what do I need to change?

I used Screen Hex Patch program that iria2 wrote (Thanks for that BTW!) but it broke with the last patch I guess.

Oh shoot! When I get home tonight, I'll find out what happened and upload a fix!

Oh shoot! When I get home tonight, I'll find out what happened and upload a fix!

EDIT: Okay, raaal, I think I know what is going on! The program still works with 1.05, i.e., no default hex values have changed. fullban and Tontondavid or anyone else who want to understand how to get the correct value, here is what to do:

You get your screen resolution of your desktop:

for example, let's say mine is 1920x1080

Divide the width of your screen by the height:

1920 divided by 1080 equals 1.7777777

Convert this number to hexadecimal:

1.7777777 in hex is 3F E3 8E 38

thankyou for explaining ..u no your stuff!

Note: try using a hex calculator like the one here and choose "auto" or "decimal" as the input format.

Reverse the byte order (or "endian") of your hex value:

3F E3 8E 38 as seen on your calculator becomes 38 8E E3 3F when reversed.

Note: Depending on how many decimal points your answer (or "decimal value") goes out, your hex value can be slightly different. This is totally fine for the most part but it is recommended to use a value as close as possible to the one you got when dividing your width by height, i.e., use those seven decimal points we got on the calculator and don't round any sooner!

The default value in MGSV is 39 8E E3 3F and the one we put in was 38 8E E3 3F. Apparently, our decimal places end a little sooner than the default value (which is 1.777777778) but in this case things are close enough that the results in game will look pretty much the same.

Does this make sense, guys? All we did was swap the order that those letter/number pairs came in.

Replace default value in your program with your reverse-byte hex value:

Use a hex editor like HxD or XVI for Windows and use their respective search tools to find and replace your hex values.

(For Mac OSX there is hexfiend or 0xED and for Linux you can use wxHexEditor, dhex, xxd, etc.)

Which finally brings me to answering raaal's problem:

The short and simple of it is, it looks like you rounded up to the nearest whole number to get your decimal value, converted it to hex but forgot to reverse it's endianness.

What happens is, when you use a hexadecimal calculator to convert your number to hex, it spits out a "big-endian" hex value. However, Intel/AMD x86 processors and specifically Windows itself, use "little-endian" for byte ordering those hex values. You pretty much always have to reverse the value you got from the hex calculator before you're ready to write it anywhere.

What you probably want to do, as well, is double-check your math. You are using 40 80 00 00 when you probably want 40 80 C0 00.

The most accurate way to get your screen's aspect ratio is to represent it in "base-10 decimal" before converting it to hex. If we do the math with your bezel corrected resolution, i.e.,

4120 / 1024 = x

we technically want the value of x to be represented like this:

4.0234375

Why? The game only understands your aspect ratio as a "single-precision floating-point value." See here and/or here for more info but the short of it is that the aspect ratio is presented to the game in a pretty specific way. We have to take our monitor resolution, and turn it into something that matches what the game expects.

The number we got from our division problem, I have represented in base-10 format which is a number represented as 10 digits total.

Note: As far as I know, most casual calculators will represent the result in base-16, rounding to the nearest positive expansion for repeating numbers. For hex calculators like the one I linked to, the end zeroes are assumed and added during conversion so you technically don't need to plug in all 10 digits.

So the next part is taking our decimal value and converting it to binary32 float (see here for more info):

The decimal value of our integer part (or "exponent" as it will be represented in binary) is 4. In binary that's 0100.

The decimal value of our fractional part (or "significand" as it will be represented in binary) is .0234375. How we represent it in binary is thus:

Assume the whole fractional value begins with 0 as it's integer and replace the decimal point with a plus sign, turning it into an expression e.g.,
0.0234375 becomes 0 + 0234375
We store the first number in our expression as the first value in our significand - the first value is 0! Next we multiply the second number by 2 to get a product we will split again.
.0234375 * 2 = (0 + .046875) - 0
.0468750 * 2 = (0 + .09375) - 0
.0937500 * 2 = (0 + .1875) - 0
.1875000 * 2 = (0 + .375) - 0
.3750000 * 2 = (0 + .75) - 0
.7500000 * 2 = (1 + .5) - 1
.5000000 * 2 = (1 + .0) - 1
.0000000 * 2 = (0 + .0)

That's how we find the significand, which is 0000011 making our floating-point binary32 value:


100.0000011

Now let's convert this to raw binary and take a look at how it's stored:


We start by converting our binary32 value to scientific notation:

[list=]1.000000011 * 2^2

Scientific notation showed us that, based on how many spaces we moved the decimal point, the base exponent is 2. To encode the raw exponent we need to add the bias (the way we store the value of the number) which is 2^8-1 or 127.

2 + 127 = 129 and in binary, that decimal value is represented as 10000001. Here is our layout:


Sign Exponent Significand
0 10000001 00000001100000000000000

Sign marks the value as positive or negative; 0 is positive. Now we can break up how the raw binary will look when represented in hex:


0100 0000 1000 0000 1100 0000 0000 0000

These values directly translate to:


40 80 C0 00

Why is this important?

You might not get the exacting bezel correction otherwise, and you forgot to swap byte order to 00 C0 80 40 That's all.

EDIT: Okay, raaal, I think I know what is going on! The program still works with 1.05, i.e., no default hex values have changed. fullban and Tontondavid or anyone else who want to understand how to get the correct value, here is what to do:

You get your screen resolution of your desktop:

for example, let's say mine is 1920x1080
Divide the width of your screen by the height:

1920 divided by 1080 equals 1.7777777
Convert this number to hexadecimal:

1.7777777 in hex is 3F E3 8E 38Note: try using a hex calculator like the one here and choose "auto" or "decimal" as the input format.
Reverse the byte order (or "endian") of your hex value:

3F E3 8E 38 as seen on your calculator becomes 38 8E E3 3F when reversed.Note: Depending on how many decimal points your answer (or "decimal value") goes out, your hex value can be slightly different. This is totally fine for the most part but it is recommended to use a value as close as possible to the one you got when dividing your width by height, i.e., use those seven decimal points we got on the calculator and don't round any sooner!The default value in MGSV is 39 8E E3 3F and the one we put in was 38 8E E3 3F. Apparently, our decimal places end a little sooner than the default value (which is 1.777777778) but in this case things are close enough that the results in game will look pretty much the same.Does this make sense, guys? All we did was swap the order that those letter/number pairs came in.
Replace default value in your program with your reverse-byte hex value:

Use a hex editor like HxD or XVI for Windows and use their respective search tools to find and replace your hex values.(For Mac OSX there is hexfiend or 0xED and for Linux you can use wxHexEditor, dhex, xxd, etc.)
Which finally brings me to answering raaal's problem:

The short and simple of it is, it looks like you rounded up to the nearest whole number to get your decimal value, converted it to hex but forgot to reverse it's endianness.

What happens is, when you use a hexadecimal calculator to convert your number to hex, it spits out a "big-endian" hex value. However, Intel/AMD x86 processors and specifically Windows itself, use "little-endian" for byte ordering those hex values. You pretty much always have to reverse the value you got from the hex calculator before you're ready to write it anywhere.

What you probably want to do, as well, is double-check your math. You are using 40 80 00 00 when you probably want 40 80 C0 00.

The most accurate way to get your screen's aspect ratio is to represent it in "base-10 decimal" before converting it to hex. If we do the math with your bezel corrected resolution, i.e.,
4120 / 1024 = xwe technically want the value of x to be represented like this:
4.0234375Why? The game only understands your aspect ratio as a "single-precision floating-point value." See here and/or here for more info but the short of it is that the aspect ratio is presented to the game in a pretty specific way. We have to take our monitor resolution, and turn it into something that matches what the game expects.

The number we got from our division problem, I have represented in base-10 format which is a number represented as 10 digits total.
Note: As far as I know, most casual calculators will represent the result in base-16, rounding to the nearest positive expansion for repeating numbers. For hex calculators like the one I linked to, the end zeroes are assumed and added during conversion so you technically don't need to plug in all 10 digits.
So the next part is taking our decimal value and converting it to binary32 float (see here for more info):

The decimal value of our integer part (or "exponent" as it will be represented in binary) is 4. In binary that's 0100.The decimal value of our fractional part (or "significand" as it will be represented in binary) is .0234375. How we represent it in binary is thus:
Assume the whole fractional value begins with 0 as it's integer and replace the decimal point with a plus sign, turning it into an expression e.g.,
0.0234375 becomes 0 + 0234375
We store the first number in our expression as the first value in our significand - the first value is 0! Next we multiply the second number by 2 to get a product we will split again.
.0234375 * 2 = (0 + .046875) - 0
.0468750 * 2 = (0 + .09375) - 0
.0937500 * 2 = (0 + .1875) - 0
.1875000 * 2 = (0 + .375) - 0
.3750000 * 2 = (0 + .75) - 0
.7500000 * 2 = (1 + .5) - 1
.5000000 * 2 = (1 + .0) - 1
.0000000 * 2 = (0 + .0)
That's how we find the significand, which is 0000011 making our floating-point binary32 value:

100.0000011
Now let's convert this to raw binary and take a look at how it's stored:

We start by converting our binary32 value to scientific notation:

[list=]1.000000011 * 2^2
Scientific notation showed us that, based on how many spaces we moved the decimal point, the base exponent is 2. To encode the raw exponent we need to add the bias (the way we store the value of the number) which is 2^8-1 or 127.

2 + 127 = 129 and in binary, that decimal value is represented as 10000001. Here is our layout:

Sign Exponent Significand
0 10000001 00000001100000000000000
Sign marks the value as positive or negative; 0 is positive. Now we can break up how the raw binary will look when represented in hex:

0100 0000 1000 0000 1100 0000 0000 0000
These values directly translate to:

40 80 C0 00
Why is this important?

You might not get the exacting bezel correction otherwise, and you forgot to swap byte order to 00 C0 80 40 That's all.