Match desktop resolution menu option?

[maseter]

Idea, a "Match desktop resolution" entry in the "set video mode" option menu, which if enabled, would set your gzdoom to the same resolution as your desktop. Which i guess is easier to implement than "set to native monitor resolution"?
The desktop resolution matches the native in what, 90% of cases anyway? So it would be good enough.

Maybe also implement something akin to the "-noborder" command line parameter and "r_noborder" cvar in call of duty, to do what is called pseudo fullscreen! Which is a game set to the same resolution as the desktop and without a window border, giving a 1:1 overlay effect.

And is it a menu bug, that is says "set video mode" in the options menu, but then only "video mode" in the menu itself?
Same for "joystick options" which then says "controller options" on the top, it's a match everywhere else, automap options says automap options and so on... Or is that too finicky? Thanks!

[Xeotroid]

Is it really that necessary? Sure, starting up at 800x600 is annoying, but that happens only until you change the resolution. You can use Borderless Gaming to make ZDoom and GZDoom um... borderless! It works quite well.

[Graf Zahl]

Is it really that necessary?

With real portable installs? Absolutely yes! My main problem with this code is that it's not something I really want to work on - far too complicated for what it's supposed to do.

[Xeotroid]

I suppose you're right, it did happen to me that a monitor didn't support 800x600 and I had to edit the .ini file manually.

[maseter]

Bump, because i had to go again into display properties on a PC to figure out the desktop resolution...
If there was a setting to just set GZDoom to the same resolution as the desktop, this would fall away.

Is it really that complicated to get the desktop resolution value? It would also be an unique feature!

And it doesn't have to be enabled by default, just give us a "matchdesktop" 0/1 cvar, thanks!

[Graf Zahl]

Have a look at the low level screen setup code. It's not pretty.

[NGX]

Have a look at the low level screen setup code. It's not pretty.

I have 0% idea what it looks like as I'm no programmer at all, but this is the type of stuff that would help presenting itself as not a complicated source-port with a lot magic-tricks, but rather a nice program that works really well.

[Alekv]

I copied the message in this topic.

But I have a question for a long time worries me, whether it is possible to automatically set the screen resolution in GZDoom?
i.e. i wrote in the .ini file
vid_defheight = 1024
vid_defwidth = 1280
on my PC it shows fine, but on a laptop another resolution.
Is it possible to make automatic detection and installation of screen resolution?
Many players do not know what aspect ratio are and are not always easy to change the resolution from the menu.
some do not know the resolution of your screen =)

As I understand it, this is done not so easy?
What to do if in the Unity engine

---

But the automatic installation screen resolution is very necessary thing.
I even here I remember myself as I opened ZDoom 1 time, I could not put the resolution as I did not even know where.

[ibm5155]

That function looks easy, why do things that sounds easy are too hard too implemente

Code: Select all

//GetSystemMetrics requires to include windows.h
//v_video.cpp
CVAR(Int, vid_defwidth, GetInitialScreenWidth(), CVAR_ARCHIVE | CVAR_GLOBALCONFIG)
CVAR(Int, vid_defheight, GetInitialScreenHeight(), CVAR_ARCHIVE | CVAR_GLOBALCONFIG)

//some isolated cpp file that will avoid conflicts
int GetInitialScreenWidth(){
	#ifdef _WIN32
	return GetSystemMetrics(SM_CXSCREEN);
	#else //method not inplemented for specific OS, use a default fixed resolution
		return 800;
}

int GetInitialScreenHeight(){
	#ifdef _WIN32
	return GetSystemMetrics(SM_CYSCREEN);
	#else //method not inplemented for specific OS, use a default fixed resolution
		return 600;
}

if SDL code could had been accessed under any platform...

EDIT:
"Is it really that complicated to get the desktop resolution value? It would also be an unique feature!"
for a single os, not actually, but there's no universal way for receiving that information (with my limited skills, but I do bevive you could have a great asm talk with the monitor and retreive that information by yourself).
so, you could add a framework under your code for doing the dirty job or you could implemente the code by yourself, for each operational system (good luck with testing )

[dpJudas]

You have to understand that the video source code has a very long history going back to a time where there was no SDL, no windows, no multitasking and no GPUs.

Nobody argues that the current code isn't bad, but to fix it requires extensive work to fix. This is because:

• SDL is not a good abstraction for all the platforms
• DirectDraw has been obsolete for 15 years
• Direct3D 9 has been deprecated for 10 years
• Direct3D 11 doesn't work with gzdoom (it needs OpenGL)
• OpenGL doesn't work with the 2D acceleration code in zdoom (without rewriting or looting it from gzdoom, that is)
• Doom was never meant for anything but 4:3 displays at 320x200. This means any resolution changing code was hacked in over the years.
• The video abstraction in zdoom are using some outdated concepts from the late 90's (such as locking a hardware surface for the software renderer). Removing this is no simple deal as you have to trace down if anything is still relying on some of it.
• CVARs that should have been shared was placed in the platform specific code.
• I could go on and on..

Complaining about its state will not get you your feature. We all already know its bad.

[Graf Zahl]

[*]Direct3D 9 has been deprecated for 10 years
[*]Direct3D 11 doesn't work with gzdoom (it needs OpenGL)

D3D9 is the only viable option here because it's the only one supported by Windows XP. This is also one reason why at this time I consider it pointless to make a D3D version of GZDoom.


Now seriously:

The entire video backend is in desperate need of being redone from scratch. The fact that it's quite overengineered with all its classes and dependencies is not going to make this easy, as a matter of fact, a lot of the modern functionality has been hacked into the class hierarchy. This all is very obvious if you consider that the base canvas class everything inherits from is not some abstract parent class but the full implementation of a software renderer. I already had my fun with that 11 years ago when I had to weed out the most inane design issues so that I could plug a hardware renderer into it.

To refactor all this into something more manageable will require a lot of hard work. (And the D3D9 code is also a nightmare all of its own with its 100k source file...)

[dpJudas]

D3D9 is the only viable option here because it's the only one supported by Windows XP. This is also one reason why at this time I consider it pointless to make a D3D version of GZDoom.

Haha, good one! I'm a bit disappointed about the dropped support for Windows 98 so early though. What IS the lowest officially supported version of Windows for zdoom anyway? Surely XP is out as its not even supported by Microsoft anymore. Windows Vista maybe?

The entire video backend is in desperate need of being redone from scratch. The fact that it's quite overengineered with all its classes and dependencies is not going to make this easy, as a matter of fact, a lot of the modern functionality has been hacked into the class hierarchy. This all is very obvious if you consider that the base canvas class everything inherits from is not some abstract parent class but the full implementation of a software renderer. I already had my fun with that 11 years ago when I had to weed out the most inane design issues so that I could plug a hardware renderer into it.

Well the funny thing is that from what I could tell there's no reason for the software renderer/DCanvas part to have anything to do with the video layer. All the video targets of today use a system memory buffer that is rendered into, and then it is copied to the screen. As such, the screen canvas could be new'ed independently from the video layer.

The only exception to this rule is the 'accel' hardware rendering done by the D3D9 target. That could be solved by using a different pointer/class entirely for that one function.

(And the D3D9 code is also a nightmare all of its own with its 100k source file...)

I actually suspect 90% of that code isn't even in use and could be deleted. Personally I would solve this part in a refactor by writing a new D3D11 class and move over the few parts from the D3D9 target I'd need. Especially since the booting code of the D3D9 target is mixed together with DirectDraw in something that might have made sense back in the 98 -> XP transition age but certainly not anymore.

[Graf Zahl]

D3D9 is the only viable option here because it's the only one supported by Windows XP. This is also one reason why at this time I consider it pointless to make a D3D version of GZDoom.

Haha, good one! I'm a bit disappointed about the dropped support for Windows 98 so early though. What IS the lowest officially supported version of Windows for zdoom anyway? Surely XP is out as its not even supported by Microsoft anymore. Windows Vista maybe?

XP. Believe it or not, a shitstorm would ensue if this was upped to Vista.

(And the D3D9 code is also a nightmare all of its own with its 100k source file...)

I actually suspect 90% of that code isn't even in use and could be deleted. Personally I would solve this part in a refactor by writing a new D3D11 class and move over the few parts from the D3D9 target I'd need. Especially since the booting code of the D3D9 target is mixed together with DirectDraw in something that might have made sense back in the 98 -> XP transition age but certainly not anymore.

Most is needed. Yes, the graphics init code is quite messed up - this is what makes it so hard for GZDoom to do it better. This stuff really need some serious refactoring.

BTW, the D3D9 code was done approximately 8-10 years ago, when first problems with DDraw on Vista started to surface, but of course at that time supporting Win95 was as essential as XP support is now (you cannot believe how many people here sit on obsolete systems and still expect things to work.)

[dpJudas]

XP. Believe it or not, a shitstorm would ensue if this was upped to Vista.

Well, that at least rules out me doing anything about it then. My opinion on this matter is that if people want to not buy a new computer in 10 years, or cling to an OS that's 15 years old, then that's their choice. But I feel in no way obligated to support their endeavors. Especially when they could solve the problem for less cash than hiring me professionally for just a few hours (i.e. by buying a 9 year old computer on ebay or something).

[Graf Zahl]

I fully understand your sentiment here, but the sad matter of fact is that those people show a resistance toward upgrading that sometimes is unbelievable. This would all not be that bad if we hadn't to consider the overall situation we are in, i.e. the entire Doom community. With no other port taking the plunge, ZDoom would be at a genuine disadvantage if it excluded XP from its supported targets and that'd really hurt.

We dropped Win98 support earlier this year, when we had to decide between backwards compatibility and C++11 features. The last ZDoom release was still compiled with Visual Studio 2005!