Emulator Issues #12789
Hazard messages are sometimes broken in Mario Golf: Toadstool Tour
Mario Golf: Toadstool Tour
GFTP01, GFTE01, GFTJ01
What's the problem? Describe what went wrong.
The hazard messages (e.g. water hazard) in Mario Golf: Toadstool Tour sometimes incorrectly stretch off of the right side of the screen.
What steps will reproduce the problem?
- Start a course
- Trigger a hazard (e.g. shoot into water)
- Observe the message
Unfortunately, sometimes this issue does not happen, and things render correctly. It's not clear what causes it. There's a chance that it's dependent on completing a course beforehand, or only randomly happens sometimes (changing when selecting a course); from what I can tell it either always or never happens after a course is started but that may just be coincidence.
The issue is also possible to reproduce with the
mario-golf-window-bug.dff fifolog, which has been confirmed to render correctly on console via the hardware fifoplayer, but renders incorrectly in Dolphin. Thus, whatever game bug is causing this issue to happen probably also randomly happens on console, but the rendering issue itself does not manifest on console.
Is the issue present in the latest development version?
Is the issue present in the latest stable version?
Yes, the issue happens in 5.0 (tested via fifolog).
What are your PC specifications?
- CPU: Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz, 2592 Mhz, 6 Core(s), 12 Logical Processor(s)
- GPU: NVIDIA GeForce GTX 1650 Ti
- OS: Windows 10 Home 10.0.19042.1415
Is there anything else that can help developers narrow down the issue?
mario-golf-window-bug.dff, object 484, offset 000c50e1:
BP register BPMEM_SCISSORTL Scissor Top: 422 Scissor Left: 502 BP register BPMEM_SCISSORBR Scissor Bottom: 677 Scissor Right: 2869
mario-golf-window-no-bug.dff (which renders correctly), object 255, offset 00074521:
BP register BPMEM_SCISSORTL Scissor Top: 422 Scissor Left: 502 BP register BPMEM_SCISSORBR Scissor Bottom: 677 Scissor Right: 821
In both cases, the scissor's left value is 502 (corresponding to 160), but in the broken case the right value is 2869 (corresponding to 2527) instead of 821 (corresponding to 479). Since 821 + 2048 = 2869, I suspect that the 2048 bit is sometimes getting set; testing for PR 10251 showed that the 2048 bit should be ignored. (PR 10251 also fixes this issue.)