A fixed `windowresolution` is not handled correctly

[ant-222]

I think the windowresolution setting in DOSBox-X is illogical and buggy. If one specifies a fixed window size, e.g.:

windowresolution = 800x600

launches DOSBox-X, and maximises its window, the game display stays the same size, although the window is properly maximized. This is a contradiction.
Furthermore, with a fixed setting the user is no longer able to stretch the window by dragging its edges. This makes no sense because the default value:

windowresolution = original

which allows resizing on-the-fly, requires (according to its name) that the window have the size of the graphical mode being emulated (with optional aspect-ratio correction).

In the original DOSBox, this setting is the only way control the size of the window. But since DOSBox-X supports dynamic resizing, I propose the following changes:

1. The setting shall be interpreted as the initial window size of the newly-started DOSBox-X (preferably in terms of the client area).

2. In case of a fixed size, stretching and maximization should work exactly as they currently do with the value original. There is no reason to disable them.

Observe also that the original DOSBox very rarely allows black borders around the window. I think DOSBox-X can prevent them too, and easily enough: by ensuring that the window have exactly the size required to accomodate the emulated display or that the emulated display fill the window's client area. The exact behavior should depend on the scaler and aspect-correction settings.

To prevent absurd window dimensions, the approach implemented in the pixel-perfect mode can be adopted:

1. With aspect=true, DOSBox-X shall calculate its window proportions according to the aspect ratio of the emulated display (which I believe is always 4:3).

2. With aspect=false DOSBox-X shall strive to preserve square pixels. It is not so simple as it may seem, because the meaning of square pixel depends upon many factors, such as:

   1. the doublescan setting,
   2. the double-width and double-height flags in the renderer,
   3. the source resolution, which may be as exotic as 256x256, 360x480, or 320x400.

My current implementation of pixel-perfect mode for DOSBox-X handles all those cases and may be used as reference.

[Wengier]

Thanks for reporting this! I have taken a look at it, and it is certainly true that the windowresolution function has some issues. You mentioned that maximizing a DOSBox-X window with a fixed window size, and the game display stays the same size, although the window is properly maximized. This is certainly the case for Surface and OpenGL outputs. On the other hand, for the Direct3D output, the game display will be properly maximized just like the window, and the resolution will stay the same as specified by the windowresolution option. Clearly, specifying a fixed window size and then maximizing it only works properly for the Direct3D output. So there are apparently some compatibility issues with other outputs, which I certainly hope they can be solved.

[ThePillenwerfer]

If you're looking at this area of the code I'll add this.

windowresolution works fine on my laptop with Intel graphics but not on a desktop PC with nVidia. On that it always starts at the same size no matter what windowresolution is set to. windowposition works fine though.

DOSBox version: 0.83.9 SDL2 32-bit
OS: Debian 10 'Buster' 32-bit with all available updates
Graphics:
  Device-1: NVIDIA G86 [GeForce 8500 GT] driver: nouveau v: kernel 
  Display: tty server: X.Org 1.20.4 driver: nouveau 
  resolution: 1280x800~60Hz 
  OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6 

Config:—

[sdl]
fullscreen=false
output=opengl
mapperfile = ~/.config/dosbox-x/mapper-dosbox-x.map
windowresolution=1054,687
windowposition=83,0

[ThePillenwerfer]

I've now tried this on a third computer, also with Intel graphics, and windowresolution isn't working on that either. The OS and DOSBox-X versions are as above.

GPU details:—

Graphics:
  Device-1: Intel 82915G/GV/910GL Integrated Graphics driver: i915 v: kernel 
  Display: x11 server: X.Org 1.20.4 driver: intel resolution: 1024x768~75Hz 
  OpenGL: renderer: Mesa DRI Intel 915G x86/MMX/SSE2 v: 1.4 Mesa 18.3.6 

I can drag the window to the shape I want:—

Then look at the DOSBox-X output and find:—

Our window lies on this CRTC display (window pos=(41,0) size=(899,687) match=(490,343))

Enter those figures into the .conf file:—

[sdl]
fullscreen        = false
fulldouble        = false
fullresolution    = desktop
windowresolution  = 899,687
windowposition    = 41,0
display           = 0
output            = opengl

and get:—

The GPU details of the lap-top I mentioned in my previous post on which it DOES work are:—

Graphics:
  Device-1: Intel Mobile 4 Series Integrated Graphics driver: i915 v: kernel 
  Display: x11 server: X.Org 1.20.4 driver: intel resolution: 1280x800~60Hz 
  OpenGL: renderer: Mesa DRI Mobile Intel GM45 Express x86/MMX/SSE2 
  v: 2.1 Mesa 18.3.6 

[rderooy]

I tried this with both the SDL1 and SDL2 version on F33 with XWayland. Using an Intel 4th Gen Core CPU with integrated graphics.

On both versions, the windowresolution seems to work fine. Just use x instead of , between the values.

• On the SDL1 version the windowposition gets ignored.
• On the SDL2 version low values of the y-axis of the windowposition get ignored, and the window is simply placed against the Gnome menu bar. Larger x or y values that would cause the window to go off-screen also get ignored, and it attempts to place the window against the screen border (which fails because of the subsequent re-sizings)

A point to note.

• On starting DOSBox-X (SDL1 or SDL2), it starts with an initial size, but then it almost immediately re-sizes the vertical window size for the "boot screen", and then it re-sizes again (horizontal and vertical) for the final size.

FYI, I ran DOSBox-x as follows:

dosbox-x -set output=opengl -set windowresolution=1054x687 -set windowposition=200,100

[ThePillenwerfer]

Thanks, Robert. It was me being an idiot with the , rather than x. All is now well on both machines.