The test to detect we cross an integer doesn't take into account 0.5
steps
When w = 9 and h = 7, you get dx = 4, dx = 5 and gradient = 0.5
In this case you never get interx + gradient > ipart(interx) + 1 when
interx is an integer.
Previously, areaSearch from usecode would use the whole bounding box of the
item and expand it by the range value on each side. However, inspecting the
disassembly shows that the range for area search opcode should be only applied
around the corner x/y of the item.
This almost never makes any difference except for the end of Mission 12 of
Crusader: No Remorse, where too many triggers get activated if the bounding box
is used, and the laser walls are enabled then disabled straight away.
The tooltip will show only if mouse cursor was moved but not on a hovered focused editText field
Changes and implications in this commit:
- Fix _lastMousePosition coordinates and time being updated upon giving focus to the tooltip
- Check for mouse cursor movement first in the decision for showing the tooltip, then check if sufficient time for mouse resting position has passed (kTooltipDelay).
- Prevents showing a tooltip for a widget if it is an editable field (editText) and has both mouse hovering above it and the current focus.
This is so that typing text is not interrupted / slowed down by a periodical display of the tooltip, if the mouse is hovering over the same text field that the user is editing.
- If mouse cursor is moved but lands on the same widget as the one that had its tooltip shown last, then show the tooltip but after a different (larger) delay kTooltipSameWidgetDelay.
- Still shows tooltip for other widgets, including editText ones, if the mouse is hovered over them and they are not the current focused editText widget.
The bug was mentioned for the Android port on the forums here:
https://forums.scummvm.org/viewtopic.php?p=95531#p95531
However, it is not Android specific, even though the slowdown is a lot more noticeable on an Android device.
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.
At least it seems to me that the way e.g. Lure of the Temptress calls
isReady() to see if the driver has finished processing all the custom
sounds, _sysExQueue can be accessed by two threads simultaneously.
Which seems like a bad thing to me!
I don't think this actually ever gets used by the usecode so probably makes no
difference, fixed it to be sure anyway. Pointer read gets used a lot, but it
was already correct.
The original codebase imported to ScummVM had two issues with it
1) The component "Dynamic Surfaces" had been incorrectly named
"Drawing Surfaces" for a while, and was only corrected later on
2) The Managed Pool component was set as version 1, but later
changed back to version 0.
This commit allows these old savegames to still be loaded
under the new, corrected codebase
Le Philousophe
Orgad Shaneh
Matthew Duggan
Filippos Karapetis
D G Turner
Cameron Cawley
lb_ii
antoniou79
Martin Gerhardy
Torbjörn Andersson
Paul Gilbert
sluicebox
alxpnv
Eugene Sandulenko