Widescreen Gaming Forum

[-noun] Web community dedicated to ensuring PC games run properly on your tablet, netbook, personal computer, HDTV and multi-monitor gaming rig.
It is currently 16 Dec 2024, 14:34

All times are UTC [ DST ]




Post new topic Reply to topic  [ 869 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23, 24, 25 ... 87  Next
Author Message
PostPosted: 10 Sep 2015, 16:52 
Offline

Joined: 16 Apr 2008, 17:16
Posts: 273
If I want to further increase the FOV value beyond what Jackfuste has done, what do I need to change?


Top
 Profile  
 


PostPosted: 10 Sep 2015, 18:19 
Offline

Joined: 18 Mar 2015, 21:25
Posts: 3
how can I get a fix for 7680x1440? what is the value for it so I can hex edit the .exe with tutorial earlier


Last edited by fullban on 10 Sep 2015, 19:10, edited 1 time in total.

Top
 Profile  
 
PostPosted: 10 Sep 2015, 18:21 
Offline
User avatar

Joined: 08 Sep 2015, 19:07
Posts: 31
CY:G wrote:
If I want to further increase the FOV value beyond what Jackfuste has done, what do I need to change?


Try the tool from iria2, you can find it on site 12 of this thread or just click the link click :twothumb:


Top
 Profile  
 
PostPosted: 10 Sep 2015, 18:53 
Offline

Joined: 09 Mar 2015, 19:17
Posts: 24
any mega pro here can change the weapon gay names ?


Top
 Profile  
 
PostPosted: 10 Sep 2015, 22:11 
Offline

Joined: 10 Sep 2015, 22:05
Posts: 6
Ok, I realize that not many people have this config but I tried to manually edit the .exe file to achieve 10320x1440 (triple ultra wide LG) and the resolution is very blurry and does not fill the entire 3 monitors....anyone else with this issue?

I used the Hex editor and did 10320/1440 and got the HEX number to be 40E55555, reversed it and input 55 55 E5 40 into the Hex file.

What am I missing?
Thanks!!


Top
 Profile  
 
PostPosted: 11 Sep 2015, 02:21 
Offline

Joined: 02 Sep 2015, 04:51
Posts: 7
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
    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.

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.


Last edited by iria2 on 11 Sep 2015, 12:32, edited 1 time in total.

Top
 Profile  
 
PostPosted: 11 Sep 2015, 10:12 
Offline
User avatar

Joined: 08 Sep 2015, 19:07
Posts: 31
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!


Thanks for the tool !! :twothumb:


Top
 Profile  
 
PostPosted: 11 Sep 2015, 12:00 
Offline

Joined: 11 Apr 2015, 12:40
Posts: 3
So, are there any fixes for the cracked edition for the game?


Top
 Profile  
 
PostPosted: 11 Sep 2015, 14:58 
Offline

Joined: 18 Mar 2015, 21:25
Posts: 3
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! :thumbup:
    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.

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.


Top
 Profile  
 
PostPosted: 11 Sep 2015, 15:16 
Offline

Joined: 10 Sep 2015, 22:05
Posts: 6
Quote:
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.


Thanks for the long explanation. I did follow what you said but I still don't get the result everyone else is getting.

First, the game does not span through all my 3 monitors, it ends about 1/3 of the way on both the left and right ones and second, the resolution looks aweful.

Not sure what I am doing wrong. I tried to do it with the 3440/1440 resolution manually (not using your tool) and the middle monitor works very well, no black bars and resolution is great. It's only once I try to go beyond that the it doesn't work.
If you don't mind, to see if I am doing it right, what hex number should I use for a resolution of 10320x1440?

Thanks for your help!!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 869 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23, 24, 25 ... 87  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  




Powered by phpBB® Forum Software © phpBB Group