Windows and macOS config files are left as they were, this change
affects mostly Linux users.
Users are not forced to migrate, but visible warning is being issued if
they aren't. Majority of users probably won't notice it, as the stable
release should generate newly named .conf file.
Change X11 Window WM_CLASS to 'dosbox-staging' to avoid conflicts with
upstream DOSBox, which might be provided by package manager.
Update .desktop file to specify WMClass to be correlated with
dosbox-staging process (even if executable file conflicts with dosbox
upstream).
Update contrib/icons/Makefile to generate 'hicolor' directory structure.
This is dosbox-staging icon (see contrib/icons/), rendered to size
128x128 with rsvg-convert (128x128 is recommended for various Linux DEs,
as this icon will mostly see usage on Linux - macOS and Windows have
icons in their native formats). Data dump created with GIMP with
following settings:
- Use 1 byte Run-Length-Encoding
- Save alpha channel
This way it's more obvious to the reader, what given parameter does
(instead of non-descriptive 'false/true'.
Create alias 'FIXED_SIZE' for 'false' meaning "non-resizable" window. It's a
constexpr bool global variable, so compiler will remind us when it'll
be time to remove it.
This call was useful during development and testing with
output=opengl, but now it's no longer necessary. This call causes
output=texture to go into initialization loop, which falls back to
surface, which we definitely do not want.
'resizable' option turns on resizable window if all the prerequisites
are met (OpenGL and compatible shader). Right now only shader 'sharp' was
tested as compatible, but other built-in shaders might be whitelisted in
the future as well (e.g. 'advmame*' shaders seem like good candidates).
Using incompatible shader does not cause any particular problems for the
users, but it looks really ugly - shader implementations clearly were
implemented only for a fixed window size.
'default' option acts as 'resizable' on Linux and 'original' everywhere
else. It also gives as an option to tweak available windowresolution
settings without causing too much disruption to end users.
It's necessary for usecase when game changes resolution while in game.
We don't want to resize the window in such case, just change minimum
size (SDL might decide to update the window size in the result, if new
resolution is higher than current window size).
This works very well when user is resizing the window and going
in/leaving fullscreen. It does not affect usecase where window size is
being updated by the emulator (e.g. game changing resolution).
Overrides previous, Windows-only hack used for the same purpose.
After initial window position, OS or window manager will take care of
emplacing window - this change takes care only of situation, when there
is NO initial window position.
Additionally, avoid re-setting the window size on every SetSDLWindowMode
call. This prevents a number of issues with the window being set to
incorrect size while switching between fullscreen and window.
Overally this change takes care of number of small issues happening on
macOS, Windows (without need for an ifdef), and Linux with KDE and MATE.
Also makes the behaviour more consistent for Gnome when starting dosbox
via XWayland.
SDL2 introduced a bunch of new events, that old SDL1.2 implementation
did not have. We probably should start using some of them…
It's also extremely helpful for comparing order/number of window events
arriving on different OSes and WMs.
Move the code to a separate function to make it easier to understand and
modify. Remove traces of windowresolution=X% support - this option
causes more harm than benefit.
Add bound checks to prevent user from setting up window size bigger then
configured display allows.
Changing this option dynamically via "config" built-in never worked, it
was always broken. Set it to change'able only on start, otherwise all
broken edge-cases would need to be fixed.
And do small cleanup in surrounding area.
Using normal2x has several undesired side-effects:
- slightly slower performance (I did some perf flamegraphs and turns out
scaler code is a significant bottleneck, even when using normal1x aka
none) - we should limit it as much as possible before addressing the
problem directly.
- it makes default glshader=sharp less precise
- it will negatively affect window resizing code
