Map scrolls to top left if mouse hasn't moved since wesnoth started

[jostephd]

To reproduce:

1. Start HttT
2. Jump to scenario 14 using :change_level
3. "Load game" and load the most recent savegame (HttT-Pluging_into_the_Darkness-Auto-Save1)

In 1.12.6, the map scrolls to Konrad. In 1.13.10+dev, it doesn't, the player starts with the viewport at the top of the map.

edit Partly fixed; see #2149 (comment) for the current status.

[Vultraz]

Assigning this to @gfgtdf since he made the save-viewport-in-savefiles change. There must be something with the gamestate when the autosave is made that puts the camera in the top left..

[gfgtdf]

turned out it was unrelated to autosaves, scroll_to_tile just by default refused to scroll to that position i it is fogged. Please test now.

[jostephd]

Thanks for the quick turnaround.

The viewport opens on Konrad, but after I press "Esc" to close the objectives dialog, it scrolls to the top. This also happened in HttT S1 and in AToTB S1, both when starting the campaigns anew and when loading the Auto-Save1 file.

This is not 100% reproducible. It seems that once this issue stopped happening in a particular wesnoth instance, it would not reproduce until wesnoth was closed and re-opened.

To clarify, in HttT S1, it scrolled to the top twice: once before the objectives were displayed, to show the player the signpost on (1,1), and once after the objectives were accepted, which is the anomaly.

[jostephd]

This is not 100% reproducible.

The rule seems to be: the issue still reproduces if the mouse has not moved since wesnoth was launched.

For example, launch wesnoth and start AToTB using the keyboard. After the objectives are displayed the viewport scrolls to (1,1). This happens again after exiting to the title menu and re-starting the campaign, but does not happen if the mouse is moved before (re-)starting the campaign.

[jostephd]

@GregoryLundberg Thanks for the additional fix but I can still reproduce the behaviour from my last comment as of 238a994.

[GregoryLundberg]

Paging @gfgtdf

I don't know how I got on the commit. Probably related to the test-master branch last night as we tried to figure out what was up with master and if we needed to do anything to fix things.

[jostephd]

Sorry for the false positive ping, I was confused by github's interface. Perhaps someone could "Reopen" this issue?

[CelticMinstrel]

Sure, I'll assume you have a reason for wanting it reopened.

[GregoryLundberg]

Confirming @jostephd report. This still is an issue.

1. Move mouse to your desk drawer. Leave it there!

2. Wesnoth MUST NOT lose focus. Perform the following from memory:

a) Start Wesnoth from the command line.
b) Press C to start a campaign.
c) Press Enter to select AToTB
d) Press Enter to accept Horseman
e) Press Esc to bypass story.
f ) Press Esc to bypass dialog
g) Press Esc to close objectives

The map will scroll to the top-left corner.

[CelticMinstrel]

Move mouse to your desk drawer. Leave it there!

This is the best instruction. XD

[gfgtdf]

i tried to reproduce but i couldn't but i also hve to say tht the esc key on this keyboard is borken so i had to user enter a few times to skip.

also this one doesn't seem to be related to reloading so ithis doesn't seem to be related to my commit.

[jostephd]

@gfgtdf Thanks. I confirm I can reproduce the issue without the Esc key, using only Space and Enter to skip.

[jostephd]

The rule seems to be: the issue still reproduces if the mouse has not moved since wesnoth was launched.

controller_base::play_slice() calls SDL_GetMouseState(), which sets mousex and mousey to 0, which causes scrolling to the top left.

wesnoth/src/controller_base.cpp

Lines 394 to 405 in 64e34f2

	int mousex, mousey;
	uint8_t mouse_flags = SDL_GetMouseState(&mousex, &mousey);
	// TODO enable after an axis choosing mechanism is implemented
	#if 0
	std::pair<double, double> values = joystick_manager_.get_mouse_axis_pair();
	mousex += values.first * 10;
	mousey += values.second * 10;
	SDL_WarpMouse(mousex, mousey);
	#endif
	scrolling_ = handle_scroll(mousex, mousey, mouse_flags, joystickx, joysticky);

I tried adding a call to SDL_PumpEvents but that didn't help.

[Wedge009]

Step 2 should be :choose_level, I think. And Step 3 should be Plunging but isn't terribly important to this issue.

1.14.9 works for me although you do state it's 'partly fixed'. What's not yet fixed? Testing 1.14.9+dev for Gregory's report on 2017-12-05 is also fine for me too - I don't get the top-left scrolling and yes I don't touch the mouse from start to finish. (At a guess maybe the mouse co-ordinates wasn't initialised until there's mouse movement and so went to 0,0, but that doesn't seem to be the case now.)

[jostephd]

What's not yet fixed?

I can reproduce the problem using @GregoryLundberg's instructions in current master.

(At a guess maybe the mouse co-ordinates wasn't initialised until there's mouse movement and so went to 0,0, but that doesn't seem to be the case now.)

That's exactly what happens. mousex and mousey default to 0 before the mouse has moved.

[Wedge009]

Strange. When was the last time you or Gregory tested? Checking master (1.15.1+dev @ 495f60d) I could not replicate the issue there either. I even switched off my (wireless) mouse to be doubly sure there were no mouse inputs.

Nonetheless, there seem to be a number of cases where mouse co-ordinates are not updated until there's mouse movement, including #1335, #1533, and #1795.

[jostephd]

I tested it just before I posted my last comment.

Those other issues are unrelated to this one. In this issue, the problem is that SDL returns 0 for the mouse position before the mouse moved. Those other three are about the scrolling event not checking what's under the mouse after the scroll.

[Wedge009]

My point is that the mouse co-ordinates are not updated till the mouse is moved.

[jostephd]

That's a good description of all four bugs, but they're still not the same. This bug occurs because we call SDL_GetMouseState and it returns 0,0. The other three issues you links are just missing code in our own GUI toolkit code.