Guild of Writers

Hi everyone,

Here is a question for people who worked on the client code for Gehn (hopefully one of your guys have time to answer it). How did you fix the problem with Uru's horizontal FOV being too wide ? I'm talking about the horrible bug when trying widescreen resolutions on MOUL.

Hoikas joked about this part of the code being written totally wrong a while ago Just wondering if you can point me to where this code was located. I had a look at the history of changes in the camera code on H-uru on GitHub, but couldn't find what I was looking for.

The thing is, I'm writing a script that parses all the PRP files in Complete Chronicles's folder to set all camera modifiers and post effect mods (for GUIs) to widescreen. However, because of this bug, I can't simply say "horizontal FOV = vertical FOV * 1.78", because otherwise it's too wide... the horizontal FOV must be set to something lower to display fine in Uru.

I know when the FOV is narrow enough, I can just say horizFOV = vertFOV * 1.78 (works for a lot of GUIs, but not all), however at wider angle the issue is more annoying... I found out when vertFOV = 66.7 deg, the horizFOV is roughly equals to 100 deg (or a 1.5 ratio instead of 1.78).

I hope you can help me with this... Would be great to get rid of this issue on Complete Chronicles too

Sirius wrote:"horizontal FOV = vertical FOV * 1.78"

This is precisely the misconception that Cyan too had in their code and that causes the wrong aspect ratios. (There may be additional reasons, I still haven’t studied this as closely as I wanted.)

The aspect ratio 1.78 (assuming you mean 16/9 by that) is a ratio of lengths, not of angles. Multiplying angles by ratios of lengths gives you nonsense, you need trigonometrical functions to convert from angles to lengths and back.

Specifically,
AR = tan(HFOV/2)/tan(VFOV/2)
or
HFOV = 2*atan(AR*tan(VFOV/2))

The code changes you’re asking for, I believe, are at https://github.com/H-uru/Plasma/pull/299.

Ok, that makes more sense then ! So, there is no problem with how rendering is done - I mean, when computing the projection matrix itself - the problem lies in the default camera settings (which apply to first and default third person), AND values Cyan put in their PRPs ?

Heh, at some point when seeing how a low FOV radius behaved fine compared to a higher one, I actually remembered my math teacher saying how tan(x) ~= x when x is small enough - and thought it was unrelated. Stupid me.

Hmmm, and let me browse code I used for a projection matrix when I was having fun with OpenGL a while ago...

Code: Select all

float f (1/tan( radians(angle)/2 ));
matrix projectionMatrix;
projectionMatrix.values[0] = f/ratio;
projectionMatrix.values[5] = f; (etc)

Stupid me. I guess I'm no smarter than they are


Anyway, will try this, thanks a lot ! I'll also release the script so people who want to can use it.