Suggest a zooming function using the mouse wheel

Bug #536461 reported by orionrobots on 2007-02-27
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

Currently the game seems not to have any use of the mouse wheel. A zoom function based on the mouse would be a good use of this control.

Related branches

bedouin (bedouin-users) wrote :

Logged In: YES
Originator: NO

Implementing zooming is ... ahemm ... not easy (we talked about it on the mailing list some time ago). The biggest problem is that with our current framework, it's a HUGE workload on the artists.

*If* we actually manage to do it one day, the wheel would indeed be a good way to control it.

tag8833 (tag8833) wrote :

Logged In: YES
Originator: NO

It appears that the graphics are PNG files, could you not simply use one of the many batch picture resizers to create say 3 copies of each image so that you can have 3 zoom levels? It would still take a bit of work, but not much for the artists, am I wrong?

Changed in widelands:
importance: Undecided → Wishlist
SirVer (sirver) wrote :

This would be a hell of work: our engine would need to be zoomable as well. This is a lot of work for a relatively minor feature in my opinnion. I vote for won't fix.

Changed in widelands:
status: New → Incomplete
Astuur (wolfsteinmetz) wrote :

Since WL has become so much more fun to view in detail with all the new graphic work that has been added lately,
I find myself sometimes going to 800 x 600, but then I miss the overview - so for playing I stay at 1920.
Perhaps the watch window could be magnifying (2x) instead of a zoom function. Would that be something that could be done with reasonble effort?

Nicolai Hähnle (nha) wrote :

Not with software rendering (it's possible, but a lot of work). However, once OpenGL support is there, we can add this feature relatively easily when OpenGL-based rendering is used.

Changed in widelands:
status: Incomplete → Triaged
Patrick H. (daggeteo) wrote :

I vote for this zooming function. Maybe not a high priority considering the amount of work that is needed but maybe further down the road I could see this being something useful!

Frank Pieper (frank-pieper-1) wrote :

Vote clearly for Zooming and suggest to use 2D-Rectangulars in 3D-Space as Canvas for OverlayPainting which means effectively "flat 3D-Models" (2D-Models inside 3D-Space instead 2D-Painting as OverLay over 3D-Scene).

tags: added: graphic opengl ui
SirVer (sirver) wrote :

Setting to incomplete for bug sweeping.

Changed in widelands:
status: Triaged → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for widelands because there has been no activity for 60 days.]

Changed in widelands:
status: Incomplete → Expired
SirVer (sirver) wrote :

I am actually working on this one and off right now. Only for OpenGL though.

Changed in widelands:
status: Expired → Confirmed
GunChleoc (gunchleoc) on 2016-10-10
tags: added: graphics
removed: graphic
kaputtnik (franku) wrote :

Zooming in editor works fine :-) Trying to start a new game results in a segfault:

widelands: /home/kaputtnik/Quellcode/widelands-repo/zoom/src/graphic/ std::unique_ptr<Texture> draw_minimap(const Widelands::EditorGameBase&, const Widelands::Player*, const Rectf&, const MiniMapType&, MiniMapLayer): Assertion `minimap_type == MiniMapType::kStaticViewWindow' failed.

Backtrace attached.

SirVer (sirver) wrote :

Right now there are still 9 NOCOMs that I still need to fix before this is ready for merging/testing. So for now, there are some known issues. That said, the particular issue is now fixed - and the editor map is now static, i.e. your viewport moves, and not the map.

GunChleoc (gunchleoc) wrote :

My mouse wheel has gone wonky, so it would be good to have a keyboard shortcut too. I vote for CTRL+/-, that's standard and still available. Ctrl+0 to return to default zoom is already taken though, unless we remove 0 from the remembered locations list.

I can start to help with testing once the problem with the fuzzy button texts has been solved.

SirVer (sirver) on 2016-10-19
Changed in widelands:
assignee: nobody → SirVer (sirver)
status: Confirmed → In Progress
GunChleoc (gunchleoc) wrote :

Button text is still fuzzy - screenshot attached.

This only affects the new font renderer, the old font renderer is fine.

kaputtnik (franku) wrote :

Which resolution do use?

I couldn't confirm fuzzy strings on buttons. Attachment shows at top the zoom branch, on bottom trunk (bzr8141). Resolution 1280 x720.

GunChleoc (gunchleoc) wrote :

I'm at 600 * 800. It gets better at 1024 * 768, but it is still there. My best guess is that the font renderer is working on a float value for the font size that should be an int instead.

SirVer (sirver) wrote :

Should be fixed r8168.

> is that the font renderer is working on a float value for the font size that should be an int instead.

Pretty close - the problem was that text was not aligned with screen pixels. For example if we centered an image that contained text that was 11 pixels wide, we would try to draw it at pos.x - 5.5f. That sounds like the correct thing to do in general, but it makes OpenGL subsample the image - which leads to bluriness. For images (for example stones on the map) we do require subpixel rendering to not make things jump while panning though, so the floats are still required.

I fixed the code to align texts always to screen pixels - I hope I found all places.

GunChleoc (gunchleoc) wrote :

You missed the game/editor tips in the progress window, everything else looks good.

SirVer (sirver) wrote :

Fixed in r8169.

SirVer (sirver) wrote :

This branch has been merged at r8148 into trunk.

Changed in widelands:
milestone: none → build20-rc1
assignee: SirVer (sirver) → nobody
status: In Progress → Fix Committed
GunChleoc (gunchleoc) wrote :

The zoom branch introduced a bug with the height of listselect - I fixed that in my dropdown branch that's up for review, so no need to fix this in trunk right now.

kaputtnik (franku) wrote :
kaputtnik (franku) wrote :
GunChleoc (gunchleoc) wrote :

This is what thezoom button looks like on my Linux at 800x600 resolution. It looks a lot better than the last one, but there are some artefacts around the rim, maybe due to scaling?

kaputtnik (franku) wrote :
kaputtnik (franku) wrote :

Sorry, the artefacts where caused by indexing the image, which i made after taking the screenshot :(

I have tried to get more sharpen "x1", and provide three alternatives: "x1", "1x" and placing the chars outside the magnifier. The right Magnifier is also better rounded, so depending on what we want to have i use this version of magnifier glass.

GunChleoc (gunchleoc) wrote :

Fixed in build20-rc1

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers