using System;
using UnityEngine;

public class CameraSizeConstraint : MonoBehaviour
{
  public float FixedWidth;
  public Transform CameraOffset;
  public Camera Camera;

  public CameraSizeConstraint()
  {
    base.\u002Ector();
  }

  private void Start()
  {
    float num = this.FixedWidth / 2f / Mathf.Tan((float) ((double) this.Camera.get_fieldOfView() / 2.0 * (Math.PI / 180.0))) / this.Camera.get_aspect();
    Vector3 localPosition = this.CameraOffset.get_localPosition();
    localPosition.z = (__Null) -(double) num;
    this.CameraOffset.set_localPosition(localPosition);
  }
}

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?)