|
|
|
Member 226 posts
Registered: Mar 2007
It worked very well for me - running QW in 1680x1050, conwidth 420, conheight 262 (1/4 of resolution). Leaves a few artifacts on the letters in the console (every 30th or so letter becomes one pixel wider than the others), and the overall FPS dropped quite considerably (from perhaps 900 to ~300). Not a problem though, since I capped it on 154 FPS and then FINALLY managed to make QW smooth by setting cl_nolerp 1 (a bit off topic, but I'm so happy right now I could cry).
Now I feel like starting a new thread just to whine over flatscreens in games. Even though I have a very fast one (2 ms), there is noticable ghosting. It's playable, but I no longer need my DX9-compatible graphics card to generate motion blur... :/
Edit: The FOV went from 110 to 119.47 if anyone is using the same and doesn't feel like doing the math. Did you change your sensitivity? Someone said that fov doesn't affect your sens, but actually it does. Try to use fov 10 and your normal sensitivity....
Member 405 posts
Registered: Jan 2006
This was posted on quakesrc.org some time ago: http://www.quakesrc.org/forums/viewtopic.php?t=5787 to correct the aspect ratio of the FOV based on the screen aspect ratio... that way fov 90 on a 16:10 monitor would resemble the same as a 4:3 monitor. but it hardcoded for fov 90, that sux. How they guess this magic r_refdef.fov_y = 73.739797; for fov 90, so later I can do it for any fov?
Moderator 1329 posts
Registered: Apr 2006
Did you change your sensitivity?
Someone said that fov doesn't affect your sens, but actually it does. Try to use fov 10 and your normal sensitivity.... I said it doesn't and it doesn't affect sensitivity. Have your sensitivy being set so that you'll get full 360 turn on your mousepad. Try using different fovs (even fov 1) and you'll still be getting the same 360 turn.
Member 485 posts
Registered: Feb 2006
Yeah, widescreen is cheat cause you can see more! :lol: :rolleyes:
Member 1011 posts
Registered: Feb 2006
How they guess this magic r_refdef.fov_y = 73.739797; for fov 90, so later I can do it for any fov? they ran CalcFov to calculate the fov_y when fov_x was 90 and the screen aspect was 4:3 here's some example code I knocked up to illustrate what they do, you should be able to port it into ezquake without much trouble - i'm at work at the mo otherwise i'd commit the source directly myself // CalcFov.c - example code to calculate correct FOV for widescreen // resolution // // quakeworld.nu - oldman
#include <stdio.h> #include <math.h> #include <stdlib.h>
static float CalcFov (float fov_x, float width, float height) { float x;
x = width / tan(fov_x / 360 * M_PI); return atan (height / x) * 360 / M_PI; }
int main(int argc, char** argv) { int width = 1280; /* int width = 960; */ int height = 720;
float fov_x, fov_y; int scr_fov = 110;
float screenaspect = (float) width / (float) height;
if (screenaspect > 1.34) { // widescreen - width is based on a target height // correct y fov for the full height view fov_y = CalcFov (scr_fov, height * (320.0f / 240.0f), height); fov_x = CalcFov (fov_y, height, width); printf("fov_x=%.8f fov_y=%.8f\n", fov_x, fov_y); } else { // tallscreen or default fov where height is based on a target width // correct x fov for the full width view fov_x = scr_fov; fov_y = CalcFov (scr_fov, width, height); printf("fov_x=%.8f fov_y=%.8f\n", fov_x, fov_y); }
return 0; }
Member 1011 posts
Registered: Feb 2006
btw i actually posted similar code to ZQuake message board on 05/08/05 so I beat mh to the idea of doing it that way and had it working for all fovs, it just never got implemented! for anyone with the zquake board archive who wants proof its in zBoard/data/9416.txt :-)
Member 357 posts
Registered: Mar 2006
but it hardcoded for fov 90, that sux. How they guess this magic r_refdef.fov_y = 73.739797; for fov 90, so later I can do it for any fov? if (screenaspect > 1.34) { r_refdef.fov_y = scr_fov.value * 0.81933107777777777777777777777778;// = 73.739797 / 90 r_refdef.fov_x = CalcFov (r_refdef.fov_y, r_refdef.vrect.height, r_refdef.vrect.width); } else { r_refdef.fov_x = scr_fov.value; r_refdef.fov_y = CalcFov (r_refdef.fov_x, r_refdef.vrect.width, r_refdef.vrect.height); } EDIT: I seemed to have replied before reading oldman's message. I think his would work better... Here's how i attempt to automatically adjust the conheight based on the conwidth value, cheap but works... qboolean OnChange_vid_conwidth (cvar_t *var, char *string) { vid.width = bound(320, (atoi(string)), vid_width.value); vid.width &= 0xfff8; // make it a multiple of eight
Cvar_SetValue("vid_conwidth", vid.width);
vid.aspect = ((float)vid_height.value / (float)vid_width.value) * (320.0 / 240.0);
//pick a conheight that matches the correct aspect if (vid.aspect < 1) vid.height = (vid.width * 0.625); else vid.height = (vid.width * 0.750);
Cvar_SetValue("vid_conheight", vid.height);
conback->width = vid.conwidth = vid.width; conback->height = vid.conheight = vid.height;
vid.recalc_refdef = 1;
return true; } cvar_t vid_conwidth = {"vid_conwidth", "640", true, false, OnChange_vid_conwidth};
Member 447 posts
Registered: Jan 2006
Did you change your sensitivity?
Someone said that fov doesn't affect your sens, but actually it does. Try to use fov 10 and your normal sensitivity.... No, as Renzo said it doesn't change. The only thing that changes is the "relative" sensitivity, meaning things seem to move faster across the screen when you move the mouse, but this is just because the screen displays a smaller vertical and horizontal angle while the sens remains static (meaning its speed, measured in degrees per mouse distance unit, is unchanged). Teamplay is nothing. Aim is everything. OBEY YOUR AIM
http://img178.imageshack.us/img178/9017/end2ub.jpg
Member 87 posts
Registered: Oct 2006
I am utterly amazed by QW activity and level of knowledge, still 10 years after it's introduction.
/PaRa
Member 1011 posts
Registered: Feb 2006
they ran CalcFov to calculate the fov_y when fov_x was 90 and the screen aspect was 4:3 I was thinking about this again today and wondering, was the original fov calculation designed for 320x200 (16:10 aspect ratio) or 320x240 (4:3 aspect ratio) ? for fov 110 in the standard calculation we get fov_x=110.00000000 fov_y=83.50372314 (320x200) fov_x=110.00000000 fov_y=93.93292236 (320x240) using these fov_y calculations for a 16:9 aspect ratio (1280x720) we get the following two: fov_x=115.56282043 fov_y=83.50372314 (1280x720 stretched from 16:10 ratio) fov_x=124.58706665 fov_y=93.93292236 (1280x720 stretched from 4:3 ratio) interestingly, if we consider that 320x240 (4:3) was the original aim of the CalcFov code then we should also revisit the fov for 320x200 and (16:10 variants) fov_x=119.47232819 fov_y=93.93291473 (320x200 stretched from 4:3 ratio) but if we consider that 320x200 (16:10) was the original aim of the CalcFov code then we should instead revisit the fov for 320x240 (and 4:3 variants) fov_x=99.92275238 fov_y=83.50372314 (320x240 shrunk from 16:10 ratio) any thoughts?
Member 2 posts
Registered: Jul 2007
Hi, I'm new here. Anyhow, for a game I play I wrote a quick Ruby script to calculate the 'optimal FOV' -- I'm not sure if it's 100% correct. But people use it in IRC channel, set it up to execute on a bot. It is easy to make implementation for game I'm sure, I was going to do it once, but you would have to make code to make sure the user's value overrides it. Maybe I will later Change the 90.0 and 4 * 3 if the game was developed for a different aspect ratio or different fov (like painkiller is 95) Sorry I didn't clean up . To run ./aafov.rb 1440x900 (or your resolution..) Name aafov.rb #!/usr/bin/ruby require 'mathn' require 'fract.rb' def calculate(resolution) #Split the 1280x1024 res into an array with each num as an element res = resolution.to_s.split('x') #Make the aspect ratio ratio = (res[0].to_f/res[1].to_f).to_fraction #Find the least common multiple, so we can get equal height aspects. lcm = ratio[1].lcm 3 #Gets put in as W2 and W1 in formula below. new_scr_w = lcm / ratio[1]*ratio[0] old_scr_w = lcm / 4 * 3 #Our formula uses degrees, Ruby uses radians. to_rad = Math: I / 180 to_deg = 180 / Math: I #The games current fov. Needs to be in radian form. cur_fov = 90.0 * to_rad #Actually calculate it. #FOV2 = 2 x Inverse Tangent [(W2/W1) x Tangent (FOV1/2)] #Where W2 and W1 are the two screen widths for equal screen height. FOV1 is the games original FOV. #Must convert end answer to degrees, as most programming languages use Radians. answer_raw = (2 * (Math.atan((new_scr_w/old_scr_w) * Math.tan(cur_fov/2))) * to_deg) #This will round our answer to the third digit. answer = (((answer_raw*1000).round)/1000).to_f return answer end puts calculate(ARGV) Name this fract.rb class Float def number_decimal_places self.to_s.length-2 end
def to_fraction higher = 10**self.number_decimal_places lower = self*higher
gcden = greatest_common_divisor(higher, lower)
return (lower/gcden).round, (higher/gcden).round end
private def greatest_common_divisor(a, b) while a%b != 0 a,b = b.round,(a%b).round end return b end end
Administrator 384 posts
Registered: Dec 2006
I guess it all depends a bit on how 'precise' you need your Quake setup to be.
When I used to play hardcore QW then I used to do stuff like this, calculating precise changes in settings when adjusting other settings. However since moving to a widescreen resolution I've simply used trial and error to pick a good FOV. You need to remember that if the screen size has changed as well as the aspect ration, then this may affect the kind of FOV you want too.
For example many years ago when I moved from 14" 4:3 monitor to 19" 4:3 monitor I also increased FOV a bit because everything was much bigger, so I could afford to use higher FOV. Obviously this changes the way the game looks/feels slightly but I felt it would be beneficial to learn to play with a higher FOV.
The funny thing is due to gradually reducing my FOV over time, I actually use lower fov now on a 8:5 screen than I used to years ago on a 4:3 screen (fov 133!).
Member 226 posts
Registered: Mar 2007
Did you change your sensitivity?
Someone said that fov doesn't affect your sens, but actually it does. Try to use fov 10 and your normal sensitivity.... No, as Renzo said it doesn't change. The only thing that changes is the "relative" sensitivity, meaning things seem to move faster across the screen when you move the mouse, but this is just because the screen displays a smaller vertical and horizontal angle while the sens remains static (meaning its speed, measured in degrees per mouse distance unit, is unchanged). I might be terribly wrong here, but... but the "relative" sensitivity is a very good reason to change your sensitivity. And the things really move faster across the screen. Have you ever tried to decrease your fov, lets say.. from 120 to 10 and keep the same sensitivity? Aiming gets really hard. Allthough, if you lower your sens you wont be able to turn as good as with a higher sens, but you're very able to aim. This is the very reason why TF snipers had "fov 10;sensitivity 1" scripts.
Member 447 posts
Registered: Jan 2006
You're not terribly wrong, you just don't grasp what we're saying. Teamplay is nothing. Aim is everything. OBEY YOUR AIM
http://img178.imageshack.us/img178/9017/end2ub.jpg
Member 364 posts
Registered: Oct 2006
I have just added a "vid_screenaspect" cvar to zquake
If you have a widescreen monitor, say 16:9, divide 16/9 and you get 1.77777... Put vid_screenaspect 1.777 into your config.cfg and you're done.
This doesn't currently work for in window modes; pixel ratio = 1.0 is assumed. But that's ok because most people will use a desktop resolution where the appearance of their programs is not distorted.
For fullscreen we still assume aspect ratio 4:3. People with widescreen monotors will likely be aware of that and will only need to set vid_screenaspect once to fix the appearance of all fullscreen modes.
The fov cvar is unchanged: it's your horizontal field of view.
Member 950 posts
Registered: Apr 2006
What does that vid_screenaspect does?
Member 364 posts
Registered: Oct 2006
It makes things look right on oldman's widescreen monitor
Member 87 posts
Registered: Oct 2006
I have just added a "vid_screenaspect" cvar to zquake
If you have a widescreen monitor, say 16:9, divide 16/9 and you get 1.77777... Put vid_screenaspect 1.777 into your config.cfg and you're done.
This doesn't currently work for in window modes; pixel ratio = 1.0 is assumed. But that's ok because most people will use a desktop resolution where the appearance of their programs is not distorted.
For fullscreen we still assume aspect ratio 4:3. People with widescreen monotors will likely be aware of that and will only need to set vid_screenaspect once to fix the appearance of all fullscreen modes.
The fov cvar is unchanged: it's your horizontal field of view. Great stuff! /PaRa
Member 48 posts
Registered: Jul 2006
hi! when i use the resolution from qwdrama wiki (-width 768 -height 480), i dont get fullscreen qw. screen: how can i solve this without taking another res.? i've got a IIYAMA TFT 22" ProLite E2201W-B1 2ms (native res 1680x1050) edit: when i use -width 960 -height 600, there is something missing on the left side of the screen..
Moderator 1329 posts
Registered: Apr 2006
hi! when i use the resolution from qwdrama wiki (-width 768 -height 480), i dont get fullscreen qw.
how can i solve this without taking another res.? It basically means that your monitor does not support the specified resolution. In windows, go to your display settings and click advanced. On "Adapter" page there is button for "List All Modes..." that should give you all the possible resolutions you can use. If you can't find 768*480 there, then you have to add it using 3rd party software.
Administrator 1265 posts
Registered: Jan 2006
will "vid_screenaspect" work on ezquake? *assuming that it will, updated wiki entry never argue with an idiot. they'll bring you back to their level and then beat you with experience.
Member 357 posts
Registered: Mar 2006
this cvar is obsolete, it should dafault 1 and use internal aspects from the initialization.
Member 121 posts
Registered: May 2006
how do i get a res like 960 x 800 to work full screen without any red stripes on it? edit: nevermind i remember now about it as i readed that thread again > http://www.quakeworld.nu/forum/viewtopic.php?id=2808 .. and apparently there's no sulution other than tweek the system to do it .. but i've tried everything on my catalyst driver and nothing happens.
|
|
|
|