The device has a 320x480 screen and aspect of gui is wrong if we use
the full resolution
Signed-off-by: Christophe Branchereau <cbranchereau@gmail.com>
Currently we have bunch of else-if and only one of them triggered. When
e.g. aspect ratio correction and resolution changes only aspect ratio is
covered by restoration. If this fails the code retries the same mode endlessly
(we don't have "shake views" - these changes of mine come from a long-abandoned experimental branch which allowed limiting the screen shaking to a certain area)
This is the original behaviour of DOS games (where the screen shakes are done by writing certain offsets into the crt cotnrol register of the vga adapter).
Usually it doesn't matter much, since the shake is an effect that passes quickly. But the difference can be noticed in cases like DOTT when switching on the stereo in green tentacle's room. The shaking will continue until the stereo is turned off again. In that case it is really more appealing if the mouse cursor "sticks" to the background.
Instead of falling back to the normal scaler if the new scale factor is
1, explicitly check if the desired scaler is available at the new scale
factor. Suggested by criezy, and I'm shamelessly copying his
implementation because this sort of C++ trickery is something I'm not
fluent in.
At the moment, this shouldn't make any difference. But I guess in the
future, there may be a scaler that's available at 3x and 4x, but not 2x,
or something like that.
Now that we have higher scale factors than 3, it makes sense to try and
figure out a default scaler for high-resolution games that approximate
the window size of a low resolution game.
That also means that we are not necessarily restricted to the normal
scaler, since AdvMame has both 2x and 4x versions.
The grabOverlay() function would only copy half the width of the
overlay. This was probably more or less visible in any game that could
show a ScummVM dialog (e.g. the pause dialog in SCUMM games, or any
message box in the Hugo games).
Is crossBlit() overkill here? Probably, but it should fall back on
copyBlit() if the source and destination formats are the same.
Besides, this way perhaps I will finally get some more feedback on how
to fix the regression.
../scummvm/gui/options.cpp: In member function 'virtual void GUI::OptionsDialog::apply()':
../scummvm/gui/options.cpp:647:82: warning: comparison of integer expressions of different signedness: 'uint' {aka 'unsigned int'} and 'int' [-Wsign-compare]
647 | else if (scalerPlugins[defaultScaler]->get<ScalerPluginObject>().getFactor() != g_system->getDefaultScaleFactor())
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==3124361== Invalid write of size 8
==3124361== at 0x483F803: memmove (vg_replace_strmem.c:1270)
==3124361== by 0x4DBF61: SurfaceSdlGraphicsManager::grabOverlay(void*, int) const (surfacesdl-graphics.cpp:1753)
==3124361== by 0x482051: ModularGraphicsBackend::grabOverlay(void*, int) (modular-backend.cpp:215)
==3124361== by 0x434EE1: GUI::ThemeEngine::clearAll() (ThemeEngine.cpp:376)
==3124361== by 0x40128E: GUI::EventRecorder::preDrawOverlayGui() (EventRecorder.cpp:558)
==3124361== by 0x481DB2: ModularGraphicsBackend::updateScreen() (modular-backend.cpp:173)
==3124361== by 0x559967: Graphics::Screen::updateScreen() (screen.cpp:62)
==3124361== by 0x55991C: Graphics::Screen::update() (screen.cpp:56)
==3124361== by 0x38AFC7: TwinE::TwineScreen::update() (twine.cpp:126)
==3124361== by 0x3B8759: TwinE::Screens::adjustPalette(unsigned char, unsigned char, unsigned char, unsigned int const*, int) (screens.cpp:150)
==3124361== by 0x3B8A89: TwinE::Screens::fadeToPal(unsigned int const*) (screens.cpp:207)
==3124361== by 0x3B8403: TwinE::Screens::loadImage(int, int, bool) (screens.cpp:80)
==3124361== Address 0x31453050 is 16 bytes after a block of size 512,000 alloc'd
==3124361== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==3124361== by 0x55B38C: Graphics::Surface::create(unsigned short, unsigned short, Graphics::PixelFormat const&) (surface.cpp:75)
==3124361== by 0x551111: Graphics::ManagedSurface::create(unsigned short, unsigned short, Graphics::PixelFormat const&) (managed_surface.cpp:153)
==3124361== by 0x4352D5: GUI::ThemeEngine::setGraphicsMode(GUI::ThemeEngine::GraphicsMode) (ThemeEngine.cpp:453)
==3124361== by 0x434A52: GUI::ThemeEngine::init() (ThemeEngine.cpp:324)
==3124361== by 0x43501B: GUI::ThemeEngine::refresh() (ThemeEngine.cpp:394)
==3124361== by 0x405780: GUI::GuiManager::screenChange() (gui-manager.cpp:603)
==3124361== by 0x405C6B: GUI::GuiManager::processEvent(Common::Event const&, GUI::Dialog*) (gui-manager.cpp:677)
==3124361== by 0x404EBA: GUI::GuiManager::runLoop() (gui-manager.cpp:429)
==3124361== by 0x3FD847: GUI::Dialog::runModal() (dialog.cpp:77)
==3124361== by 0x36D747: launcherDialog() (main.cpp:106)
==3124361== by 0x36FF92: scummvm_main (main.cpp:552)
It looks like the _videoMode.overlayHeight in SurfaceSdlGraphicsManager::grabOverlay and ThemeEngine::_backBuffer::h are somehow out of sync after
starting the game in a different resolution as the gui was started with. So the overlayHeight is updated - but the backbuffer (Surface) is not resized.
This is with event recorder being active - right after starting the game and switching the resolution.
Force the creation of a new screen buffer for the scaler after leaving the overlay. The whole "old source" code looks a bit unfinished. Anyway, this fix should only kick in for one particular scaler and one particular situation and one particular backend. So I guess it is safe enough...
OSystem now just returns a nullptr if there is no text to speech manager instance
(because none is compiled into the binary, or the system doesn't provide support
for it). This removed the need for the engine authors to add scummvm osystem compile
time options checks into their engine code
Vladimir Serbinenko
Cameron Cawley
Christophe Branchereau
Le Philousophe
Eugene Sandulenko
athrxx
Orgad Shaneh
Paweł Kołodziejski
Vanfanel
Torbjörn Andersson
Thierry Crozat
Paul Gilbert
Martin Gerhardy
SupSuper