[-noun] Web community dedicated to ensuring PC games run properly on your tablet, netbook, personal computer, HDTV and multi-monitor gaming rig.
https://www.wsgf.org/phpBB3/
bigodon wrote:can you please provide me a hex values (from to, change) for me change mines to 5120x2160, 3840x1620 and 3413x1440? I use nvidia DSR and would like to have those resolutions
thanks
CY:G wrote:If I want to further increase the FOV value beyond what Jackfuste has done, what do I need to change?
raaal wrote:I used Screen Hex Patch program that iria2 wrote (Thanks for that BTW!) but it broke with the last patch I guess.
iria2 wrote:raaal wrote: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!
iria2 wrote:raaal wrote: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!
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.