Widescreen support about dhewm3

[motorsep]

To make that happen, you need to use OS capability to query the driver I believe. idTech4 doesn't have that. dhewm3 never implemented that. So you can simply add more resolutions to the list in the engine and let menu display confirmation box after vid_restart was applied, with timeout and reverting back to the last resolution selected. This way if player chooses wrong resolution, he won't be able to see confirmation menu and resolution would be set back safely.

As far as making engine detecting all available resolutions, there are some cons that come with the method. Anyhow, DarkPlaces engine has automatic detection of resolutions implemented. Although it's in C, it can be easily ported to dhewm3, but no one is going to do that :(

[libcg]

Thank you for your great help.

I might take a look at the DarkPlaces engine to see how it is achieved. I'm interested enough to try something in my fork.

motorsep [email protected] a écrit :

To make that happen, you need to use OS capability to query the driver I believe. idTech4 doesn't have that. dhewm3 never implemented that. So you can simply add more resolutions to the list in the engine and let menu display confirmation box after vid_restart was applied, with timeout and reverting back to the last resolution selected. This way if player chooses wrong resolution, he won't be able to see confirmation menu and resolution would be set back safely.

As far as making engine detecting all available resolutions, there are some cons that come with the method. Anyhow, DarkPlaces engine has automatic detection of resolutions implemented. Although it's in C, it can be easily ported to dhewm3, but no one is going to do that :(

---

Reply to this email directly or view it on GitHub:
#37 (comment)

[andre-d]

SDL_ListModes

On Fri, Aug 24, 2012 at 10:33 AM, Clément Guérin
[email protected]:

Thank you for your great help.

I might take a look at the DarkPlaces engine to see how it is achieved.
I'm interested enough to try something in my fork.

motorsep [email protected] a écrit :

To make that happen, you need to use OS capability to query the driver I
believe. idTech4 doesn't have that. dhewm3 never implemented that. So you
can simply add more resolutions to the list in the engine and let menu
display confirmation box after vid_restart was applied, with timeout and
reverting back to the last resolution selected. This way if player chooses
wrong resolution, he won't be able to see confirmation menu and resolution
would be set back safely.

As far as making engine detecting all available resolutions, there are
some cons that come with the method. Anyhow, DarkPlaces engine has
automatic detection of resolutions implemented. Although it's in C, it can
be easily ported to dhewm3, but no one is going to do that :(

---

Reply to this email directly or view it on GitHub:
#37 (comment)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8003037.

[motorsep]

Omg, andre-d is around !!! :) On different issues, could you please look into them: #36 , #35 , #18 ?

On auto-detecting resolutions, DarkPlaces also detects them in non-SDL builds.

[andre-d]

I definitely cannot help with any windows issues as I have no windows
install.

On Fri, Aug 24, 2012 at 10:53 AM, motorsep [email protected] wrote:

Omg, andre-d is around !!! :) On different issues, could you please look
into them: #36 ,
#35 ,
#18 ?

On auto-detecting resolutions, DarkPlaces also detects them in non-SDL
builds.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8003638.

[andre-d]

As for detecting resolution, the SDL method is all we need.

On Fri, Aug 24, 2012 at 11:21 AM, Andre D [email protected] wrote:

I definitely cannot help with any windows issues as I have no windows
install.

On Fri, Aug 24, 2012 at 10:53 AM, motorsep [email protected]:

Omg, andre-d is around !!! :) On different issues, could you please look
into them: #36 ,
#35 ,
#18 ?

On auto-detecting resolutions, DarkPlaces also detects them in non-SDL
builds.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8003638.

[libcg]

OK then, I'll take a look at it :)

Since I run Linux I can't help too.

[motorsep]

Gotcha guys. Would someone care to add icon to the fork for Linux and Windows ? (using SDL I suppose)

[libcg]

I think it deserves a new issue.

----- Mail original -----
De: "motorsep" [email protected]
À: "dhewm/dhewm3" [email protected]
Cc: "Clément Guérin" [email protected]
Envoyé: Vendredi 24 Août 2012 17:55:59
Objet: Re: [dhewm3] Widescreen support (#37)

Gotcha guys. Would someone care to add icon to the fork for Linux and Windows ? (using SDL I suppose)

—
Reply to this email directly or view it on GitHub .

[motorsep]

I think I created it as separate issue long time ago, but no one added icon support :/

Added #38

[motorsep]

Speaking of resolution detection, how are you going to pass it into the menu? The menu relies on the engine's list (which you will create using SDL_ListModes) and on the string # in strings/english.lang file. So when you switch r_mode, it takes corresponding text from the string and draws it on the screen. String is static, it's predefined.

[andre-d]

Yeah, that code would need to be changed for the list to be dynamic.

[motorsep]

but then you (or whoever will be making this autodetection of resolutions) will loose compatibility with vanilla Doom 3, unless you make a patch / guide for the mainmenu.gui to accept dynamic resolutions

[andre-d]

dhewm3 already has network incompatibility with doom3. Might as well have
menu incompatibility?

On Fri, Aug 24, 2012 at 5:15 PM, motorsep [email protected] wrote:

but then you (or whoever will be making this autodetection of resolutions)
will loose compatibility with vanilla Doom 3, unless you make a patch /
guide for the mainmenu.gui to accept dynamic resolutions

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8015049.

[motorsep]

Network is not content. You can compile dhewm3, drop it into game's root with dlls and play. If you get engine incompatible with stock content, no one would even bother using it. Unless, as I mentioned, there is mainmenu.gui comes with dhewm3 (or in any other form, maybe as mod or pk4 that gets dropped into base/ and d3xp/ ) which will work with autodetection of resolution.

[andre-d]

So we will have an updated mainmenu.gui? I do not see the problem.

On Sat, Aug 25, 2012 at 12:19 PM, motorsep [email protected] wrote:

Network is not content. You can compile dhewm3, drop it into game's root
with dlls and play. If you get engine incompatible with stock content, no
one would even bother using it. Unless, as I mentioned, there is
mainmenu.gui comes with dhewm3 (or in any other form, maybe as mod or pk4
that gets dropped into base/ and d3xp/ ) which will work with autodetection
of resolution.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8024789.

[andre-d]

Additionally, the old mainmenu.gui would still work, just those with the
new one would get to take advantage of our dynamic resolution listing.

On Sat, Aug 25, 2012 at 1:30 PM, Andre D [email protected] wrote:

So we will have an updated mainmenu.gui? I do not see the problem.

On Sat, Aug 25, 2012 at 12:19 PM, motorsep [email protected]:

Network is not content. You can compile dhewm3, drop it into game's root
with dlls and play. If you get engine incompatible with stock content, no
one would even bother using it. Unless, as I mentioned, there is
mainmenu.gui comes with dhewm3 (or in any other form, maybe as mod or pk4
that gets dropped into base/ and d3xp/ ) which will work with autodetection
of resolution.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8024789.

[motorsep]

Alright :) The only thing is that mainmenu.gui is not under GPL. So it has to be something like a mod or w/e, uploaded to filefront for example.

[andre-d]

Or we could just write a new mainmenu.gui under the GPL. How large is it?
Is there any way we can just write a new item for the menu without
replacing the entire menu?

On Sat, Aug 25, 2012 at 1:32 PM, motorsep [email protected] wrote:

Alright :) The only thing is that mainmenu.gui is not under GPL. So it has
to be something like a mod or w/e, uploaded to filefront for example.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8025516.

[motorsep]

Pretty big. 21446 lines of script o_O

[andre-d]

Can we use the scripting language to inject into the menu?

On Sat, Aug 25, 2012 at 1:36 PM, motorsep [email protected] wrote:

Pretty big. 21446 lines of script o_O

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8025548.

[motorsep]

well, it is scripting already. Here is how it looks like:

choiceDef OS2Primary {
rect 210, 1, 100, 14
choices "#str_04222"//320x240;400x300;512x384;
values "3;4;5;6;7;8"//0;1;2;
cvar "r_mode"
updateGroup render

So values are what is fed to r_mode according to choices user made while selecting resolution. #str_04222 is read from the strings/english.lang and is "#str_04222" "640x480;800x600;1024x768;1152x864;1280x1024;1600x1200".

So if you choose 640x480 in the menu, it will set value of r_mode cvar to 3, 800x600 to 4 and so on.

[andre-d]

I am thinking we can write a small script which adds an item to the menu and removes the old one. I am unsure how global that sort of thing is though and if we can do that.

[libcg]

I don't see any problem here. If the list is dynamically generated we don't use a little part of the gui, and that's it.

Edit: Oh well I see the problem now. We could use r_mode to choose a resolution from the list of found ones. But then, how can we display it to the GUI?

[motorsep]

Exactly my point. Plus, the way it's set up right now, it's localization ready. All you have to do is use different language (I assume Japanese, Korean, etc. might have symbols for numbers, but I might be wrong).

Another thing is you can edit the string to change the way resolutions appear (which might not be the case with auto detection). For example, in SS2 we simply use Widescreen option and when it's selected, only 16:9 and 16:10 resolutions are displayed. While 16:9 resolutions appear as usual, 16:10 have [16:10] suffix to them. This way user can identify which one is which. It's crude, but I as designer have control over appearance.

[scaronni]

I'm patching my neo/renderer/RenderSystem_init.cpp file to add the additional resolutions:

https://github.com/scaronni/dhewm3/commit/1144a584300dcef365eb92eedbfe974b6f46842d

And patching a copy of mainmenu.gui to show the additional resolutions:

https://github.com/scaronni/dhewm3/commit/29aa3bb62acc28564b725f766d550226fcd8c009

This removes the translations entirely, but I doubt there's a released zpak (I own only european zpaks) that use additional characters instead of numbers.

[scaronni]

Any chance to see mode "-2" like in ioquake3 which gets the desktop resolution?

http://svn.icculus.org/quake3?view=rev&revision=2311

[motorsep]

I don't see the point in what you've done. It's not autodetection for once. You removing 4:3 aspect ration resolution. What's the thinking?

Why did you remove translation string? Also, "wide" can be 16:9 and 16:10. And since you removed string, there is no way to translate it.

[scaronni]

Please note I have not yet tested it, it was a quick fork to show an idea instead of posting changes here in the comments.

• It's not for autodetection, the autodetection maybe can be taken from the second comment, from the ioquake3 changelog.
• The 4:3 resolution has not been removed, I simply added additional resolutions from taking the list from ioquake3 and changing the default from 640x480 to 800x600.
• As stated in the comment, I know this removes the translations entirely, but I doubt there's a released zpak (I own only european zpaks) that use additional characters instead of numbers.

What are the additional common 16:10/16:9 resolutions other than those listed?

[motorsep]

http://en.wikipedia.org/wiki/List_of_common_resolutions

[scaronni]

Hello, I'm no programmer, but I managed to make autodetection work using the ioquake3 commit as an example with the SDL_GetVideoInfo function:

http://sdl.beuc.net/sdl.wiki/SDL_GetVideoInfo

I wrote a 7 lines patch that enables the "-2" r_mode by autodetecting it from SDL.

I removed the following lines in my config file:

seta r_customHeight "1050"
seta r_customWidth "1680"
seta r_fullscreen "1"
seta r_mode "-1"

And just set:

r_mode "-2"

The game starts full screen, and when I load a save game I can get the native resolution of my monitor. Here is the patch; probably there's some better way to do this, but C/C++ is something completely new for me:

diff -Naur dhewm3.old/neo/renderer/RenderSystem_init.cpp dhewm3/neo/renderer/RenderSystem_init.cpp
--- dhewm3.old/neo/renderer/RenderSystem_init.cpp       2012-07-28 12:54:25.000000000 +0200
+++ dhewm3/neo/renderer/RenderSystem_init.cpp   2012-08-28 13:56:13.088874248 +0200
@@ -37,7 +37,7 @@
 #include "renderer/GuiModel.h"
 #include "sound/sound.h"
 #include "ui/UserInterface.h"
-
+#include <SDL.h>
 #include "renderer/tr_local.h"

 // Vista OpenGL wrapper check
@@ -51,6 +51,8 @@

 const char *r_rendererArgs[] = { "best", "arb2", NULL };

+const SDL_VideoInfo* videoInfo = SDL_GetVideoInfo();
+
 idCVar r_inhibitFragmentProgram( "r_inhibitFragmentProgram", "0", CVAR_RENDERER | CVAR_BOOL, "ignore the fragment program extension" );
 idCVar r_useLightPortalFlow( "r_useLightPortalFlow", "1", CVAR_RENDERER | CVAR_BOOL, "use a more precise area reference determination" );
 idCVar r_multiSamples( "r_multiSamples", "0", CVAR_RENDERER | CVAR_ARCHIVE | CVAR_INTEGER, "number of antialiasing samples" );
@@ -487,6 +489,12 @@
                return true;
        }

+       if ( mode == -2 ) {
+                *width = videoInfo->current_w;
+                *height = videoInfo->current_h;
+                return true;
+        }
+
        vm = &r_vidModes[mode];

        if ( width ) {

The only problem I have is with my dual monitor setup (laptop's lid closed, 2 external 1680x1050 monitors). If you set the resolution manually in the game's interface, the second monitor gets disabled (through Randr) upon first startup; but with autodetection it tries to set up a visual with 4800x1050 which is not available so the game sets r_mode "3" in the config file:

----- Warnings -----
during dhewm 3 initialization...
WARNING: No usable GL mode found: No video mode large enough for 4800x1050

[andre-d]

I believe you need to setup some kind of meta resolution for the two monitors, but even then the second monitor will still disable for you (It did for me). My solution is to not use exclusive fullscreen with two monitors and to stick to windowed mode or using things which ask the window manager to fullscreen them, rather than the driver.

[scaronni]

btw, I have bought a copy of Oil Rush, which uses SDL and the UniGine engine. This is the only game I have that sets fullscreen on the monitor I have the mouse on (like a normal window) and does not disable the second monitor during runtime and when closing the app.

[andre-d]

They likely modified SDL such that it uses NETWM_FULLSCREEN or they do a
trick with maximizing it with no borders and putting it at 0,0

If you like, try sauerbraten, lemme know if that fullscreens correctly.

On Tue, Aug 28, 2012 at 8:44 AM, scaronni [email protected] wrote:

btw, I have bought a copy of Oil Rush, which uses SDL and the UniGine
engine. This is the only game I have that sets fullscreen on the monitor I
have the mouse on (like a normal window) and does not disable the second
monitor during runtime and when closing the app.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-8090141.

[motorsep]

@scaronni: Try Xonotic or Steel Storm (they powered by DarkPlaces engine which supports autodetection of resolution and multi-monitor setup)

[scaronni]

@andre-d: sauerbraten exhibits the same behaviour as dhewm3

@motorsep: Xonotic works like Oil Rush for the GLX version, while the SDL version sets up correctly the first monitor (leaving the second one running with the desktop) but when exiting the game the second monitor gets disabled.

[scaronni]

@andre-d: what kind of network incompatibility is there in dhewm3 compared to the original doom3 binary?

I was asking myself what's the purpose of having a cdkey if the game cannot connect to the official servers for multiplayer.

[andre-d]

The CD key is there because I have no idea....

The protocol version was changed: 20aaba2 here

[DanielGibson]

Ok, I added lots of resolutions to r_vidModes[] and wrote a really ugly hack that replaces the hardcoded shit from mainmenu.gui with strings generated from r_vidmodes[].

It's not in master yet but in the widescreen branch, see https://github.com/dhewm/dhewm3/tree/widescreen

If anyone still is interested in this (3 years later ;-)) please test it - as it's kinda ugly I didn't feel confident to immediately put this into master.

[DanielGibson]

the first feedback I got for that change was positive so I merged it into master.