Zoom on MouseWheel() centered on cursor location

[Flatline]

As suggested in http://www.freeorion.org/index.php/Prog ... map_screen , I did a quick patch. Just change your MapWnd::MouseWheel function with:

Code: Select all

void MapWnd::MouseWheel(const GG::Pt& pt, int move, GG::Flags<GG::ModKey> mod_keys)
{
   if ( ( m_zoom_factor!=s_max_scale_factor || move < 0) && (m_zoom_factor!=s_min_scale_factor || move > 0) ) { 
      std::pair<double, double> move_to = UniversePositionFromScreenCoords(pt);
      CenterOnMapCoord(move_to.first,move_to.second);
      Zoom(move);
   }
}

While at max zoom in/out more rotating of the wheel in/out isn't counted (i.e. the map won't center on the cursor location just by keep on rotating the wheel in the same direction): I tried it (just by adding lines 4-5 to the if in the MouseWheel() function on SVN), and it felt a bit... strange, so I put in the extra check.

Easy isn't it?

Anyway, with these large steps in zoom variation using the wheel feels a little too "jumpy"... could we just turn down a little bit the step?

And perhaps we should code a more gentle movement between the various zoom factors (like what a real camera would do).

[Geoff the Medio]

Instead of duplicating all the zoom range checks that are already in MapWnd::Zoom, and instead of recentering the view immediately before zooming which recentres it again anyway, it would be better to make MapWnd::Zoom take the screen coords or world coords and do the recentring in one step, and leave MapWnd::MouseWheel as simple as it was before.

[Flatline]

Instead of duplicating all the zoom range checks that are already in MapWnd::Zoom, and instead of recentering the view immediately before zooming which recentres it again anyway, it would be better to make MapWnd::Zoom take the screen coords or world coords and do the recentring in one step, and leave MapWnd::MouseWheel as simple as it was before.

Ok, this afternoon I'll work on it

[tzlaine]

Things aren't so simple. I've implemented a "zoom-panning" mousewheel scheme for something atr work, and you have to track the original location, not just the current location of the mouse. Otherwise, where you zoom to changes as you move the mouse, which looks awful. In short, don't worry about this one, since it's on my TODO list, and the code is written.

[Flatline]

Things aren't so simple. I've implemented a "zoom-panning" mousewheel scheme for something atr work, and you have to track the original location, not just the current location of the mouse. Otherwise, where you zoom to changes as you move the mouse, which looks awful. In short, don't worry about this one, since it's on my TODO list, and the code is written.

Eheheh I just arrived home, so you stopped me in time, thanks

[eleazar]

On a remotely related topic,
has anyone noticed that when scrolling, the background parallax stars jump around in an irrelevant manner?

I don't think a zoom should cause them to move at all, relative to the screen.

[pd]

This has to do with the fact, that they don't zoom at all and work the same on all zoom steps. It doesn't bother me, since zooming isn't continuous, though.

[eleazar]

This has to do with the fact, that they don't zoom at all...

I know the background stars don't zoom— nor should they. I don't see what that has to do with the background jerking when you scroll.

[pd]

The background tiles always start at the top left corner of the map. Depending on the zoom step, a different crop of this area is visible, which might seem like jerking sometimes. Or are we talking about 2 different things maybe?