[New Feature] Mouse Wheel zooming

[StefanP.MUC]

I just implemented mouse wheel zooming (along with some code-internal optimizations to the camera movement code).

Holding down CTRL and turning your mouse will zoom in or out along the z axis (not along the camera view axis).

Turning the wheel without CTRL still rotates the creatures in hand.

This topic is for discussion of tweaking this features.

Here are some question that maybe, maybe not need some discussion:
Should the zooming go along the z axis or the current view axis of the camera?
Should we use another button than Shift/CTRL?
Should we use Shift/CTRL (or another button) on creature rotating instead on the zooming?

[Skorpio]

Should the zooming go along the z axis or the current view axis of the camera?

I'd like to see that in-game, before I comment on it.

Should we use another button than Shift?

I prefer Ctrl-MMB, because I'm used to Blender zooming. Shift-MMB is panning in Blender.

[StefanP.MUC]

OK, I changed it to CTRL. Personally I have no preference to the key, because I prefer zooming with only the wheel. But I think we had a discussion where many people suggested a combination.

About the zoom axis:
I'm not sure how, in the end, the camera "freedomness" is planned.
Should the player be able to fly around freely:
-> x-y-z movement without limits and rotation around x-y-z?
Or do we want a system like most startegy games use:
-> x-y-z movement with limits and rotation only around z?

[svenskmand]

I will also wait to comment on the preferred axis before I have tried it in game. But regarding the ctrl button then I think we should leave it up to the user. For the defaults I think we should dedicate a thread to discuss which keys we think is most intuitive to have as the default for the game. But keys should NOT be fixed, they should be user-configurable.

[StefanP.MUC]

Agreed. I think we should decide on options and non-options and how to implement it very soon, anyways. The further the code develops the harder it will get to convert hardcoded stuff into user-changable stuff.

[svenskmand]

Indeed, so we should probably put a "user-configureable keys" task on the todo list of 0.4.9.

By the way I just tried the latest version out from git, and the mouse wheel+ctrl is only toggling to zoom in or out at a constant pace, i.e. it keeps moving when I do not move the mouse wheel. That is very unintuitive, it should only zoom when I move the wheel, it should not be a toggle button.

Regarding the keys they I would suggest to also have shift+wheel to rotate around the axis that is orthogonal to the floor, i.e. the equivalent of shift+wheel-up would be the keyboard key delete and the equivalent of shift+wheel-down would be the keyboard key page-down, or vice-versa.

[StefanP.MUC]

Strange, I had this "toggle" problem yesterday, but I thought I fixed it... I'll have a look into it.

[StefanP.MUC]

Fixed.

But while I moved all the camera movement and input stuff into their own classes, I noticed some flaws (especially performance no-go's) anyways (because it was the Ogre example code - again - extended randomly with OD specifics). This whole thing could need some rewrites (I started doing this).

[oln]

Agreed. I think we should decide on options and non-options and how to implement it very soon, anyways. The further the code develops the harder it will get to convert hardcoded stuff into user-changable stuff.

Agreed. We should consider some class to handle options and save/load them. I think andrews plan was to do this by providing it as input to the in-game console (similar to half-life/source engine games.). This is a possibility, but that would require some work and cleanup of the console handling.

[StefanP.MUC]

Now that you mention the console: In the TODO text file that lays on git there's a comment about a complete remake of the console by something like this: http://www.ogre3d.org/tikiwiki/OgreCons ... e=Cookbook

It doesn't look to hard to implement and would push the game a huge step forward.