It is a good find b0n3z, thanks. It is aspect we want. Have some ideas at least now, need to build somehow later.
-----
The most disturbing code, most likely the problem:
MaintainAspectRatio.cs
1. First of all, dev has used "1.77777..." a fair amount in this dll. That is why so many 16:9 aspect hits in hex. I think. Switching them does not improve the logic, so that hex don't fix game. I think, something like that.
2. The main issue here (I think) is dev's new & funky 21:9 code (2.389f), stuck snuggly in here. I think that's got to go, somehow. In a manor of speaking (the flow could be shoved with a hardcode, or the 21:9 value changed to a logical value that would alter the flow)
3. Guess1 (strong guess): Change the dll's hex for 21:9, to something else, to affect the Clamp statement's effect on flow.
Code: Select all
4. Tuning... will describe some vars in this area. This is rough, sharing thought
A. 'num1 = your proper aspect, temp-stored here.
'eg0 num1=1.333333333 (4:3) (!)
'eg1 num1=1.777777778 (16:9)
'eg2 num1=2.388888889 (3440x1440, ~21:9)
'eg3 num1=3.259259259 (3520x1080, ~16:5) (!)
'eg4 num1=5.333333333 (LLL 16:9x3) (!)
B. 'num2 looks faulty, is used as a flag. It is compared with num1 to decide a horrible fait. I think.
'Clamp is used to direct aspect-range's future flow (branch of two, one is bad & should be shunned).
'num2 shuns your wide aspect (via clamp), storing instead 21:9 (for flagging, not actual visuals yet).
'eg0 num1 of 1.333333333 = num2 of 1.777777778 (!)
'eg1 num1 of 1.777777778 = num2 of 1.777777778
'eg2 num1 of 2.388888889 = num2 of 2.388888889
'eg3 num1 of 3.259259259 = num2 of 2.388888889 (!!!)
'eg4 num1 of 5.333333333 = num2 of 2.388888889 (!!!)
C. height (used first as a flag):
'i. Examples
'eg0 height = 0.75 (!)
'eg1 height = 1.0
'eg2 height = 1.0
'eg3 height = 1.364341085 (!!!)
'eg4 height = 2.232558140 (!!!)
'ii. Logic branch (BAD I think):
'- if height > 1.0 (eg PLP, LLL; we are forced into this BAD branch atm), then
'- 1. store (eg):
'- - eg3: new width-variable = 0.732954545 (ie 1/height-variable, ie 1/1.364341085)
'- - eg4: new width-variable = 0.447916667 (ie 1/height-variable, ie 1/2.232558140)
'- 2. width-variable then thrown to Rect (____), along with height (of 1, for all egs, including eg3).
'- - means: these values will be used to calc later (are not your actual px/aspect-values, here). But we can fix logic here, for later.
'= 3. OutputGuess1: appears nasty code, whining for pillarbox.
'= - eg3: 3520 x 0.732954545 (width-variable) = 2580 pxWidth, which will auto-use 1080, which is about ~21:9, a hint wider (2560x1080 would be dead-proper 21:9).
'= = = This is exactly what I see in-game (game-image bare-hint-wider than 21:9). Our first test of theory passes.
'= - eg4: 5760 x 0.447916667 (width-variable) = 2580 pxWidth, which will auto-use 1080, which is about ~21:9, a hint wider (2560x1080 would be dead-proper 21:9).
'= = = Same exact 21:9 output. This villian.
------WE ARE HERE-------
'iii. Logic flow (GOOD BRANCH. we PLP/LLL want to shove over to this branch. Sort of):
'- if height < 1.0 (ie, eg0 of 4:3; PLP can't get in here atm), then
'1. width-variable is never used (ie it will not mess with our wider-aspects). Rect is instead sent 1 (for width; which will likely = [x yours = yours]. your proper width's aspect, in theory)
'2. It uses height variable & defaults to your width (1x yours), which appears exactly what we want.
'3. This branch is evil toward 4:3. I think. It will letterbox narrow aspect. I think.
'4. If we force our way here, the height needs a fudge. I think. This is a spanner in the works. I think, hope can think around it. I don't know it could block, very easily.
'= - eg0: 1200 (pxHt) x 0.75 (height-variable) = 900 (!)
'= - eg1: 1080 (pxHt) x 1.0 (height-variable) = 1080
'= - eg2: 1440 (pxHt) x 1.0 (height-variable) = 1440
'= - eg3: 1080 (pxHt) x 1.364341085 (height-variable) = 1473.488372000 (!!! what would that do?)
'= - eg4: 1080 (pxHt) x 2.232558140 (height-variable) = 2411.162791000 (!!! what would that do?)
'MOST IMPORTANTLY, FOR THE GAMBLER (test at your own risk. I have not yet, still feeling around)
'- Logic (you can ignore): 2.389f == 4018E560 >>format>> 60E51840.
'- TO TEST ~GOOD BRANCH:
'Open Assembly-CSharp.dll in HxD. Find 60E51840, replace with __something else__ (evil grin) that is a lot bigger or smaller. It don't matter much, because I can't think which way. One way is right, the other way will make no difference. So 50-50 chance, you try both ways & see.
Post now complete. No more post edits.
----------
At this point, it remains feasible this can be corrected with hex or CE. But not certain yet. There is also I chance I can decompile, fix, recompile (using other tools). But that plain sucks if hex will suffice
