User panel stuff on forum
  53 posts on 2 pages  First page12Last page
General Discussion
2007-07-17, 09:41
Member
226 posts

Registered:
Mar 2007
ui wrote:
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....
2007-07-17, 10:32
Member
405 posts

Registered:
Jan 2006
SputnikUtah wrote:
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?
<3
2007-07-17, 11:25
Moderator
1329 posts

Registered:
Apr 2006
PEKTOPAHKY wrote:
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.
Servers: Troopers
2007-07-17, 11:50
Member
485 posts

Registered:
Feb 2006
Quote:

Yeah, widescreen is cheat cause you can see more! :lol: :rolleyes:
2007-07-17, 11:54
Member
1011 posts

Registered:
Feb 2006
qqshka wrote:
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;
}
2007-07-17, 12:07
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 :-)
2007-07-17, 18:28
Member
357 posts

Registered:
Mar 2006
qqshka wrote:
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};
2007-07-17, 22:18
Member
447 posts

Registered:
Jan 2006
PEKTOPAHKY wrote:
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
2007-07-28, 21:15
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
2007-08-02, 07:59
Member
1011 posts

Registered:
Feb 2006
oldman wrote:
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?
2007-08-04, 01:31
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
2007-08-05, 07:35
Member
367 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!).
2007-10-16, 13:20
Member
226 posts

Registered:
Mar 2007
ui wrote:
PEKTOPAHKY wrote:
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.
2007-10-16, 22:24
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
2007-11-05, 19:09
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.
2007-11-05, 19:17
Member
950 posts

Registered:
Apr 2006
What does that vid_screenaspect does?
2007-11-05, 19:27
Member
364 posts

Registered:
Oct 2006
It makes things look right on oldman's widescreen monitor
2007-11-13, 21:12
Member
87 posts

Registered:
Oct 2006
Tonik wrote:
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
2008-01-04, 19:46
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:

http://img181.imageshack.us/img181/2108/rescn7.th.jpg


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..
2008-01-05, 04:02
Moderator
1329 posts

Registered:
Apr 2006
ori wrote:
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.
Servers: Troopers
2008-05-05, 13:51
Administrator
1246 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.
2008-05-06, 04:30
Member
357 posts

Registered:
Mar 2006
this cvar is obsolete, it should dafault 1 and use internal aspects from the initialization.
2009-01-13, 12:34
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?

http://img237.imageshack.us/img237/9656/ps0000000000000234tk3.th.jpg


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.
. - - -- Words are stones in my Mouth.. -- - - . [url=http://profile.xfire.com/katataniel][img]http://miniprofile.xfire.com/bg/sh/type/2/katataniel
  53 posts on 2 pages  First page12Last page