View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004022||The Dark Mod||Coding||public||08.01.2015 20:29||16.02.2019 09:53|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Product Version||TDM 2.03|
|Target Version||TDM 2.07||Fixed in Version||TDM 2.07|
|Summary||0004022: Change default screen resolution?|
|Description||In the default 640x480 screen resolution, it's sometimes tough to read the menu selections.|
The suggestion is to bump the default res to 800x600 or even 1024x768.
|Tags||No tags attached.|
This issue is here again (2.06 beta):
1. Increase default resolution from 640 x 480 to 1024 x 768 (cvar change).
2. Do not change resolution on startup, i.e. add special "native" value for resolution.
3. Detect native resolution and set cvar to it by default (e.g. on first launch).
|What if we change the default to 1024x768 for 2.06 and investigate resolution detection in 2.07? The latter sounds like it needs some interrogation code that doesn't exist now.|
|That seems like a decent way to address it this late in the game.|
|Done. Rev 7278.|
|Re-targetted to 2.07 to allow investigation of resolution detection?|
|Yes. I can create a new tracker for that if you prefer?|
I propose to move completely to FBO in 2.07 and get rid of the screen resolutions paradigm.
I.e. just open the full-screen window on the user's desktop and render to FBO of configurable size, then stretch that to the TDM window.
It's much easier and image quality is better due to linear magnification filter.
> I propose to move completely to FBO in 2.07
I agree with that. Just make sure to implement some homebrew AA =)
> get rid of the screen resolutions paradigm
I don't get this.
So you suggest to remove the ability to change screen resolution? So whichever resolution user has currently, will be used in fullscreen TDM, no other possibilities?
I don't agree with this.
Also I think rendering FBO of size different from screen resolution is generally not a good idea (except for 2x, 3x resolutions): it increases interpolation error on the image.
On the other hand, how do modern monitors handle nonnative resolution? I guess they do the same: interpolate the output to their native resolution...
Why change user's screen resolution when we can render to FBO of any resolution?
It screws other program windows, especially on multi-monitor systems.
And like you wrote above, monitor scaling is no better than GPU scaling.
Look at any mobile game - none offer screen resolution options. They always render to native resolution, no matter how high it is and how low-power device processor is.
CRT monitors could actually change their resolution, while LCD monitors cannot --- they simply rescale whatever you throw at them if it is not native. This explains why all old games provided control over resolution.
I guess we can ignore CRT monitors now...
Mobile games are not a thing to compare with. Can mobiles change display resolution at all?
Mobile games cannot change resolution and they are not supposed to. But if all mobile games somehow manage to run on most mobile devices it kinda proves my point that resolution option is not necessary at all.
Talk about your average PC gamer with a FullHD screen. He can't go any higher than that (unless video driver provides virtual resolutions that we _already_ have in TDM) and he won't need to go any lower because we will have an option to render at 90% (80, 70, ...) of native screen size. Monitor internal scaling usually sucks so no one uses it unless they can't get decent FPS in native resolution - which we allow a better alternative to.
I have added a related issue 0004724, dedicated to so-called windowed borderless mode.
It seems that this is exactly the same as you talked about. Such a mode is very popular in modern games (I'm talking about serious games like e.g. Quantum Break, not about mobile games). I don't think removing fullscreen mode is a good idea, but windowed borderless mode seems to be much better default than some hard-coded fullscreen.
To my shame, I don't know the difference between windowed borderless (maximized) and fullscreen.
Could you explain it to me?
I suspect, it has something to do with ws_popup/always on top?
The current default resolution is 720x486.
I think someone mistook that for 720p?
720p should be 1280x720
Anyway, it's no longer 640x480. We should consider closing this in favor of later
investigation in 4724
If I remove my config and start TDM, then I get 1024x768.
Moreover, since FBO is enabled by default now, I get a borderless window which thinks it is fullscreen =)
Having fullscreen working completely different with FBO on and off is unpleasant and probably unnecessary. The best end result would be having fullscreen/windowed/borderless-window modes regardless of FBO.
Anyway, 4724 is closed as "not a problem" and automatic detection is not done. Maybe discuss this question on the forum before closing?
Automatic resolution detection was added somewhere in revisions 7818-7823.
Right now if user runs TDM without darkmod.cfg, then r_customWidth and r_customHeight are both 0 (default). This triggers the call to Sys_GetCurrentMonitorResolution, and the current desktop resolution is set into these two cvars.
To trigger automatic resolution detection manually, set both cvars to 0 and restart game.
Duzenko, do you still indend to do something for this issue?
I think it is fully resolved now...
|The current state works for me but 2.07 beta testers might find something be something we missed|
|Since we are only waiting for feedback from the beta testers, I think we can leave this in target version 2.07 instead of 2.08.|
|2.07 has been released|
|08.01.2015 20:29||grayman||New Issue|
|11.11.2017 15:44||stgatilov||Note Added: 0009570|
|11.11.2017 15:44||stgatilov||Note Edited: 0009570||View Revisions|
|11.11.2017 15:52||grayman||Note Added: 0009571|
|11.11.2017 16:13||Springheel||Note Added: 0009573|
|11.11.2017 16:15||grayman||Assigned To||=> grayman|
|11.11.2017 16:15||grayman||Status||new => assigned|
|11.11.2017 16:15||grayman||Target Version||=> TDM 2.06|
|12.11.2017 02:00||grayman||Note Added: 0009579|
|22.11.2017 06:17||nbohr1more||Status||assigned => feedback|
|22.11.2017 06:17||nbohr1more||Target Version||TDM 2.06 => TDM 2.07|
|22.11.2017 15:09||grayman||Note Added: 0009675|
|22.11.2017 15:09||grayman||Status||feedback => assigned|
|22.11.2017 15:31||nbohr1more||Note Added: 0009676|
|22.11.2017 15:52||grayman||Note Added: 0009677|
|23.11.2017 10:11||duzenko||Note Added: 0009679|
|23.11.2017 10:12||duzenko||Note Edited: 0009679||View Revisions|
|23.11.2017 15:22||stgatilov||Note Added: 0009681|
|23.11.2017 15:27||duzenko||Note Added: 0009682|
|23.11.2017 15:28||duzenko||Note Edited: 0009682||View Revisions|
|23.11.2017 16:08||stgatilov||Note Added: 0009683|
|23.11.2017 16:25||duzenko||Note Added: 0009684|
|23.11.2017 17:06||grayman||Assigned To||grayman =>|
|23.11.2017 17:06||grayman||Status||assigned => acknowledged|
|03.01.2018 15:38||stgatilov||Relationship added||related to 0004724|
|03.01.2018 15:41||stgatilov||Note Added: 0009968|
|03.01.2018 15:52||duzenko||Note Added: 0009970|
|11.12.2018 03:16||nbohr1more||Note Added: 0010866|
|11.12.2018 04:18||stgatilov||Note Added: 0010868|
|15.12.2018 08:23||stgatilov||Note Added: 0010930|
|15.12.2018 09:19||duzenko||Assigned To||=> duzenko|
|15.12.2018 09:19||duzenko||Status||acknowledged => assigned|
|18.12.2018 17:24||stgatilov||Note Added: 0010962|
|18.12.2018 17:37||duzenko||Note Added: 0010963|
|19.12.2018 12:46||stgatilov||Status||assigned => feedback|
|20.12.2018 05:29||nbohr1more||Target Version||TDM 2.07 => TDM 2.08|
|20.12.2018 11:43||STiFU||Note Added: 0010993|
|21.12.2018 19:54||nbohr1more||Relationship added||related to 0004124|
|16.02.2019 07:44||duzenko||Note Added: 0011606|
|16.02.2019 07:44||duzenko||Status||feedback => resolved|
|16.02.2019 07:44||duzenko||Fixed in Version||=> TDM 2.07|
|16.02.2019 07:44||duzenko||Resolution||open => fixed|
|16.02.2019 09:53||nbohr1more||Target Version||TDM 2.08 => TDM 2.07|