User panel stuff on forum
  20 posts on 1 page  1
Advanced Configuration
2014-05-28, 21:20
News Writer
912 posts

Registered:
Jan 2006
I was previously using the following on a 16:10 screen:
vid_conheight "267"
vid_conwidth "512"
vid_displayfrequency "120"
vid_mode "13"
vid_wideaspect "1"
default_fov "108"
fov "126.454147"

I now have changed to a 16:9 screen and i wish to have the same feeling as my old screen by adjusting conwidth and height however I cannot figure out how to do this... The fact I have vid_wideaspect 1 enabled seems to automate these values and I believe a lot of them came from nQuake 2 years ago.

Does anyone know how to convert these values to keep the same feel as I had before? Perhaps someone who has upgraded from a Samsung 2233RZ to a FullHD res monitor can help...
2014-05-28, 21:24
Administrator
1025 posts

Registered:
Apr 2006
dirtbox wrote:
I was previously using the following on a 16:10 screen:
vid_conheight "267"
vid_conwidth "512"
vid_displayfrequency "120"
vid_mode "13"
vid_wideaspect "1"
default_fov "108"
fov "126.454147"

I now have changed to a 16:9 screen and i wish to have the same feeling as my old screen by adjusting conwidth and height however I cannot figure out how to do this... The fact I have vid_wideaspect 1 enabled seems to automate these values and I believe a lot of them came from nQuake 2 years ago.

Does anyone know how to convert these values to keep the same feel as I had before? Perhaps someone who has upgraded from a Samsung 2233RZ to a FullHD res monitor can help...

Unfortunately that's not easy to do with ezQuake 2.x. These versions have a hardcoded 16:10 aspect ratio built in to calculations... ezQuake 3.0 however fixes this by letting you use the same fov for all resolutions/aspect ratios. Let's see when I get time to do some kind of 3.0 alpha release. (wideaspect, vid_mode, displayfrequency are all removed cvars in 3.0, stuff is being dealt with automagically there. vid_width/vid_height are used to set resolution if other than desktop res is wanted.)
2014-05-28, 21:28
News Writer
912 posts

Registered:
Jan 2006
you are a gentleman and a scholar dimman

(for those that don't know, this is the highest compliment a man can give another man in the english language)
2014-05-28, 22:05
Member
286 posts

Registered:
Sep 2012
Maybe you can try that then dirtbox http://www.speedyshare.com/B59Q5/ezquake30alpha.zip
2014-06-01, 14:16
News Writer
912 posts

Registered:
Jan 2006
Jissse wrote:
Maybe you can try that then dirtbox http://www.speedyshare.com/B59Q5/ezquake30alpha.zip
I just gave this a go and indeed I was able to set my resolution, set my FOV to my regular fov of 108 (not the wide calculated one) and instantly everything felt like how I wanted it...

There was some problems though... The textures looked quite weird especially on dm2. Demo's also wouldn't play...

http://s21.postimg.org/twap64vif/ezquake008.png

above, you see the green colour of 3.0 build

http://s14.postimg.org/keej5xc9t/ezquake011.jpg

here is what i am used to seeing in any other version
2014-06-01, 14:21
Member
286 posts

Registered:
Sep 2012
Well, report to dimman, that's an alpha build of ezquake 3.0 someone gave me, so I can't help you much
2014-06-01, 15:01
Administrator
1025 posts

Registered:
Apr 2006
dirtbox wrote:
Jissse wrote:
Maybe you can try that then dirtbox http://www.speedyshare.com/B59Q5/ezquake30alpha.zip
I just gave this a go and indeed I was able to set my resolution, set my FOV to my regular fov of 108 (not the wide calculated one) and instantly everything felt like how I wanted it...

There was some problems though... The textures looked quite weird especially on dm2. Demo's also wouldn't play...

http://s21.postimg.org/twap64vif/ezquake008.png

above, you see the green colour of 3.0 build

http://s14.postimg.org/keej5xc9t/ezquake011.jpg

here is what i am used to seeing in any other version

Try gl_brush_polygonoffset 25 (if that doesn't help, try 0) (was previously hardcoded.. But when using Intel GFX it should be 0 otherwise one will see glitches like you do.)

EDIT: Actually, that might be just one of the problems. The other might be if you're using an older build with OpenGL based gamma. I reverted that back to regular gamma system in one of the latest commits.
2014-06-01, 19:35
News Writer
912 posts

Registered:
Jan 2006
dimman wrote:
Try gl_brush_polygonoffset 25 (if that doesn't help, try 0) (was previously hardcoded.. But when using Intel GFX it should be 0 otherwise one will see glitches like you do.)

EDIT: Actually, that might be just one of the problems. The other might be if you're using an older build with OpenGL based gamma. I reverted that back to regular gamma system in one of the latest commits.
That command doesn't appear to do anything. It could be an old build. Neither playing back MVD's or spectating by QTV works.

I don't want to waste your time with trying to troubleshoot an old build. Is it possible I can get a copy of the latest nightly?
2014-06-02, 07:05
Member
215 posts

Registered:
Feb 2011
dirtbox wrote:
That command doesn't appear to do anything. It could be an old build. Neither playing back MVD's or spectating by QTV works.

I don't want to waste your time with trying to troubleshoot an old build. Is it possible I can get a copy of the latest nightly?

Try the link from post #3 @ here, it might be newer than the build you have.
2014-06-02, 07:52
Member
124 posts

Registered:
Apr 2012
dimman wrote:
EDIT: Actually, that might be just one of the problems. The other might be if you're using an older build with OpenGL based gamma. I reverted that back to regular gamma system in one of the latest commits.


Totally don't mean to de-rail anything, but I thought I might randomly point out that one of the main reasons that I don't use the latest ezQuake version (I just compiled from a fresh clone from git again to test) is because /gl_gamma stopped working for me unless I run it with a window manager like fluxbox or something, which I don't. :<

I might take a look and see what the problem is some day. I know you've cleaned the code up a lot from the mess that I remember it being, so thanks for all the hard work so far!
2014-06-02, 14:13
Administrator
1025 posts

Registered:
Apr 2006
cream wrote:
dimman wrote:
EDIT: Actually, that might be just one of the problems. The other might be if you're using an older build with OpenGL based gamma. I reverted that back to regular gamma system in one of the latest commits.


Totally don't mean to de-rail anything, but I thought I might randomly point out that one of the main reasons that I don't use the latest ezQuake version (I just compiled from a fresh clone from git again to test) is because /gl_gamma stopped working for me unless I run it with a window manager like fluxbox or something, which I don't. :<

I might take a look and see what the problem is some day. I know you've cleaned the code up a lot from the mess that I remember it being, so thanks for all the hard work so far!

Roger that. Well I used OpenGL shaders for a while for gamma, try checking the history and see if you like that version. However now gamma is being handled by SDL2 so what happens is fully up to what the SDL2 library implements to do. Try upgrading your lib to the latest version first.

May I ask how you are launcing ezQuake? A lot of of guides etc recommend to run it in its own Xserver session etc, but please don't do this. It will only introduce more problems than what it will solve today. Even alt-tab shall work in almost all cases today with SDL2.
2014-06-02, 14:45
Member
188 posts

Registered:
Feb 2008
https://bugzilla.libsdl.org/show_bug.cgi?id=1680

sdl_setgamma and friends (both sdl 1.2 and sdl2 ) don't work with newer X11 (1.7 onwards) servers. This is an old bug, still unsolved.
It may work with the nvidia blob drivers, can't remember though.

For quakespasm (sdl 1.2) it can be worked around by setting
SDL_VIDEO_X11_NODIRECTCOLOR=1
in the environment however this a) may be luck and b) doesn't help for sdl2.

Yeah, OSS cares about its users.
"Your project fixes it" "No, you" "No, you" ad infinitum

Here I use XF86VidModeSetGammaRamp again for ezquake 3 but that is not really the right thing to do.

As a workaround go with
$ xgamma -gamma 1.6
or
$ xrandr --output <MONITOR-ID> --brightness 1.6:1.6:1.6
2014-06-02, 16:02
Administrator
1025 posts

Registered:
Apr 2006
leopold wrote:
https://bugzilla.libsdl.org/show_bug.cgi?id=1680

sdl_setgamma and friends (both sdl 1.2 and sdl2 ) don't work with newer X11 (1.7 onwards) servers. This is an old bug, still unsolved.
It may work with the nvidia blob drivers, can't remember though.

For quakespasm (sdl 1.2) it can be worked around by setting
SDL_VIDEO_X11_NODIRECTCOLOR=1
in the environment however this a) may be luck and b) doesn't help for sdl2.

Yeah, OSS cares about its users.
"Your project fixes it" "No, you" "No, you" ad infinitum

Here I use XF86VidModeSetGammaRamp again for ezquake 3 but that is not really the right thing to do.

As a workaround go with
$ xgamma -gamma 1.6
or
$ xrandr --output <MONITOR-ID> --brightness 1.6:1.6:1.6

Lets see if I get time to do a temporary workaround for Linux using XF86VidModeSetGammaRamp while they sort it out...
2014-06-02, 18:29
Member
357 posts

Registered:
Mar 2006
if you want to force your console to the native aspect ratio of your monitor, (not the aspect ratio of the resolution)

aspect = width/height

then

vid_conheight = width * aspect


______________________________________________________________________________________________________

//R00k realtime console resizing
extern mpic_t *conback;
qboolean OnChange_vid_conheight (cvar_t *var, char *string)
{
vid.height = bound(200, (atoi(string)), vid_height.value);
//vid.height &= 0xfff8;// make it a multiple of eight
Cvar_SetValue("vid_conheight", vid.height);
conback->height = vid.conheight = vid.height;

vid.recalc_refdef = 1;

return true;
}
cvar_t vid_conheight = {"vid_conheight", "480", true, false, OnChange_vid_conheight};

qboolean OnChange_vid_conwidth (cvar_t *var, char *string)
{
extern cvar_t vid_conwidth;

vid.width = bound(320, (atoi(string)), vid_width.value);
vid.width &= 0xfff8;// make it a multiple of eight
Cvar_SetValue("vid_conwidth", vid.width);

//pick a conheight that matches the correct aspect
if ((vid_force_aspect_ratio.value)&&(!windowed))
vid.height = (vid.width * vid.nativeaspect);//Set aspect to the monitor's native resolution not current mode.
else
vid.height = (vid.width * vid.aspect);

vid.height = bound(200, vid.height, vid_height.value);

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};
//R00k realtime console resizing--end
2014-06-02, 18:46
Administrator
1025 posts

Registered:
Apr 2006
ezQuake 3.0 has vid_width and vid_height, if any of them is set to 0, the desktop resolution is used.

Same goes for console resolution in 3.0:
If any of vid_conwidth and vid_conheight is set to 0, the console resolution is set to whatever resolution is used divided by vid_conscale (default 2).

You can resize the window at any time, console gets autoupdated too.
2014-06-02, 19:41
Member
22 posts

Registered:
Jan 2013
vid_conscale will be a nice addition. More intuitive to work with (than doing console height/width math), and it's basically the way that the Fitzquake/DirectQ family of engines have been handling things.
2014-06-02, 23:21
Administrator
886 posts

Registered:
Jan 2006
leopold wrote:
https://bugzilla.libsdl.org/show_bug.cgi?id=1680

sdl_setgamma and friends (both sdl 1.2 and sdl2 ) don't work with newer X11 (1.7 onwards) servers. This is an old bug, still unsolved.
It may work with the nvidia blob drivers, can't remember though.

For quakespasm (sdl 1.2) it can be worked around by setting
SDL_VIDEO_X11_NODIRECTCOLOR=1
in the environment however this a) may be luck and b) doesn't help for sdl2.

Yeah, OSS cares about its users.
"Your project fixes it" "No, you" "No, you" ad infinitum

Here I use XF86VidModeSetGammaRamp again for ezquake 3 but that is not really the right thing to do.

As a workaround go with
$ xgamma -gamma 1.6
or
$ xrandr --output <MONITOR-ID> --brightness 1.6:1.6:1.6


I lol'd. In a good way. Sorry to disturb y'all.
Join us on discord.quake.world
2014-06-03, 15:36
Member
357 posts

Registered:
Mar 2006
Johnny Law wrote:
vid_conscale will be a nice addition. More intuitive to work with (than doing console height/width math), and it's basically the way that the Fitzquake/DirectQ family of engines have been handling things.


true, but handling the adjustments within the menu, instead of console, you really dont need a vid_conscale cvar, your settings are already saved with vid_conwidth and vid_conheight...*shrugs*

case 5:
con_size += 1;
con_size = bound (1,con_size,6);
if ((vid_width.value / con_size) < 320)
con_size -= 1;
set = (vid_width.value / con_size);
Cvar_SetValue ("vid_conwidth", set);
break;

con_height is automatically adjusted based on aspect ratio....(well at least in mine), not sure how ezQ3 is doing it.... just a suggestion.
2014-06-03, 16:29
Administrator
1025 posts

Registered:
Apr 2006
SputnikUtah wrote:
con_height is automatically adjusted based on aspect ratio....(well at least in mine), not sure how ezQ3 is doing it.... just a suggestion.

The ratio between width and height is your aspect ratio.

As I said, in ezQuake 3.0 you can set any of vid_conwidth/conheight to 0 and it will automatically scale conwidth/conheight to be vid_width/vid_conscale for conwidth and vid_height/vid_conscale for conheight.
2014-06-03, 16:49
News Writer
912 posts

Registered:
Jan 2006
It is worth noting that I get 40fps higher in a timedemo (an intensive 4on4 demo i use for all of my testing) in ezQuake 3.0-alpha666 compared to 2.2-stable. Keep up the good work!
  20 posts on 1 page  1