this might happen if you have EventSource instances registered, that
are querying the millis by themselves, too. If the EventRecorder::poll
is registered and thus dispatched after those EventSource instances, it
might look like it ran out-of-sync.
==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.
Fixes clearing all debug flags set on the command line
whenever the ScummVM save/load dialog is displayed from
within a game.
This reverts commit 1c4e15599f4a88aaba903952f0cfb385a5d0f213
Opening the load dialog, to display thumbnails into PicButtonWidget objects,
a call to setGfx creates a temporary ManagedSurface from a Surface but is
not instantiated, so not freed.
Same fix applied in GraphicsWidget which code is the same and reported
as potential memory leak by clang-tidy.
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
When starting a game from the command line for a target that had
not previously been added, a temporary target is created. When
subsequently returning to the launcher, it would attempt to
include that temporary target in list of games (and crash when
trying to get the path with an unknown key error as those
temporary targets do not have a path value set, which is actually
how I noticed the issue).
The same rect was hardcoded in three different places. Now it is
only in getEditRect and the other places use getEditRect.
There were actually differences between the rect width, but I put
that down to a bug in getEditRect. I see no reason to define the
right position of the rect as w - 2 - right_padding - left_padding.
Substracting the left padding would make sense if we were
specifying the rect width, but the Common:Rect constructor takes
the rect right location and not the width. There might have been
a confusion on that point by the developer who wrote that code
years ago. Also has the bottom right point is excluded, we should
only remove 1 and not 2.
This width that was smaller than it should be might have been the
reason why 6 additional pixels were arbitrarily added to the rect
passed to setTextDrawableArea later on.
There were actually
There was a discrepency in the vertical position of the text in
the drawText call on one hand, and in the getEditRect() and rect
passed to setTextDrawableArea() on the other. This discrepency
was introduced in commit c47b204ac. Since getEditRect() is used
in EditableWidget::drawCaret() to draw the character after the
caret (when erasing the caret) this caused this vertical shift.
This fixes bug #12336.
