Opened 4 months ago
Closed 4 months ago
#15264 closed defect (fixed)
TUCKER: Unable to go to Lower Hall (Dolny korytarz) in 2nd Chapter
Reported by: | m-stefanski | Owned by: | antoniou79 |
---|---|---|---|
Priority: | normal | Component: | Engine: Tucker |
Version: | Keywords: | walk to bottom exit | |
Cc: | Game: | Bud Tucker |
Description (last modified by )
- ScummVM version: 2.8.1 (latest)
- Repro steps: In chapter 2 when in hall location with Beryl, try to go to lower hall (bottom of the screen). Arrow for changing location shows, but clicking does not result in anything.
- Game language: Polish
- Game version: CD
- Platform and Compiler: macOS ARM clang 14.0.0
Error seems to be already reported in 2012: https://forums.scummvm.org/viewtopic.php?t=11342
Attachments (3)
Change History (9)
by , 4 months ago
Attachment: | tucker-pl.3 added |
---|
by , 4 months ago
Attachment: | scummvm.log added |
---|
by , 4 months ago
Attachment: | Zrzut ekranu 2024-07-12 o 17.07.59.png added |
---|
comment:1 by , 4 months ago
Description: | modified (diff) |
---|
comment:2 by , 4 months ago
comment:3 by , 4 months ago
Component: | --Unset-- → Engine: Tucker |
---|---|
Keywords: | walk to bottom exit added |
I think I've figured the cause of this.
There's some code that tries to access unallocated memory (outside the bounds of the space allocated to an array called _locationBackgroundMaskBuf).
Windows handles this more *conveniently* for the game's purposes, but other backends probably don't.
The culprit seems to be in the method: TuckerEngine::testLocationMask(int x, int y)
wherein there's already some code that looks like a workaround but I am unsure if that was put in to address specifically a similar bug or something else.
If we put an
assert (offset < 640 * 140);
before the "return" line trying to access _locationBackgroundMaskBuf[offset], then it throws assertion fault there. (640x140 is the size allocated to _locationBackgroundMaskBuf)
I think I have a potential fix for this. I'll issue a PR later today, if possible.
comment:6 by , 4 months ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed in the PR above
I can confirm that I'm also seeing the issue on our Android (2.9 dev build) app, with the touch interface (it does not matter if the control mode is direct mouse or touchpad emulation) and with a physical mouse connected to the Android device.
I don't have a MacOS device (or an iOS device) to test on, though.
I seems like the "click" is registered in the sense that the character moves to the bottom of the screen, if he's not there already, but the engine does not register that it should also switch rooms.
On Windows (2.8.1 and also recent 2.9 dev build) I cannot reproduce this issue. The character walks to the next room as expected.