Smallmap zoom/Minimap zoom

[adf88]

That is always the case with non-anti-aliased scaling down, you just need to get lucky when binning!

Heh, the luck is not a thing that programmer should hope to.
Our minimap is not a common case of non-anti-aliased scaling. We have some extra assumption - we draw rail lines. And we can use this assumption.
Look on this exemplary pattern for 4x zoom out:

This pattern is 4x4 cells (for better results it must be bigger). Green tile determines the type (rail or not rail) of whole cell. Algorithm (very simple):
(dx, dy) = (y % N, x % N), where

• (x, y) - cell index
  (dx, dy) - offset of green tile in cell
  N - zoom level

Notice that all vertical and horizontal tracks would be well displayed, the assumption

choosing one tile from whole cell results in drawing tracks as dots, the distance between dots should be regular (as much as possible) and should correspond to zoom level and track thickness

is agreed. Each single track is one dot per N cells, each double-track line is 2 dots per N cells etc.
But it's not good for diagonal tracks.

[fonso]

Maybe like this?

Code: Select all

if (this->zoom > ZOOM_LVL_NORMAL) {
	uint mod = 1 << (this->zoom - ZOOM_LVL_NORMAL);
	x += ((yc ^ xc >> 1)) % mod;
	y += ((xc ^ yc >> 1)) % mod;
}

where xc and yc are the "raw", scaled coordinates. See the screenshot for an example in full zoom out.

[fonso]

I have implemented some antialiasing. The patches:

• http://fickzoo.com/fonsinchen/patches/c ... m-out.diff for zoom-out
• http://fickzoo.com/fonsinchen/patches/c ... evels.diff for zoomlevels
• http://fickzoo.com/fonsinchen/patches/c ... om-in.diff for zoom-in on top of zoom-out and zoomlevels
• http://fickzoo.com/fonsinchen/patches/c ... om-in.diff for all three combined

The patches apply to this trunk version: http://fickzoo.com/fonsinchen/patches/c ... ERSION.txt
They are regularly semi-automatically updated.

[Bilbo]

Hmm ... what about allowing player to toggle antialiasing on/off for zoom-in/zoom-out zoomlevels? This will result in only one patch and then everybody can set these settings according to their preferences and speed of their CPU ....

[fonso]

Hmm ... what about allowing player to toggle antialiasing on/off for zoom-in/zoom-out zoomlevels? This will result in only one patch and then everybody can set these settings according to their preferences and speed of their CPU ....

The current implementation doesn't take more CPU power than the one without antialiasing. zoom-in doesn't have antialiasing anyway. But if there is anyone who doesn't like the antialiasing for a reason which is not a bug I can make a setting for it. The same goes for other settings. Go ahead and tell me. The number of patches is not a reflection on people's wishes concerning functionality. I've deliberately split up the code to allow easier merging into trunk. As I said: You can always get an all-in-one patch here: http://fickzoo.com/fonsinchen/patches/c ... om-in.diff

[Blood Angel]

please tell me: will this patch implement to nightly build (and when)?

[NukeBuster]

Fonso, have you updated the flyspray I posted the link from?
Just add a comment with the updated files.

Good job on the improvements, I hope this patch will finally end up in the trunk.

[fonso]

The last comment in the flyspray task is indeed from me and it says the patches at the specified locations are always up to date. So as long as there are no functional changes (which there aren't) there's no need to post more comments.

The devs are still pondering if it's appropriate to use the ZoomLevel enum for the smallmap. ZoomLevels was invented for the main viewport and some other code doesn't expect zoom-in levels. This is why I had to change some otherwise unrelated code in order to make zoom-in work. Some people don't like that. Others say zoom-in is unneeded. This is why I split the patch in zoom-out, zoomlevels and zoom-in. Like this zoom-out can be merged on its own, without changing unrelated code and without zoom-in. Of course I can make my own SmallmapZoomLevel enum instead, but before I do that I'd like to know if that will be accepted.

Personally I think we should only have one zoom levels type. And the main viewport should eventually support zoom-in, too. So I'd keep it as it is, but if it helps to get the patch accepted I'll change it to whatever a consensus among the devs says.

Another problem is the issue with the "subscroll" field in SmallMapWindow. I have removed it along with a lot of code dedicated to manipulating it as I don't see what it does. The smallmap still works fine so I concluded it doesn't do anything useful. However, even after numerous changes to the smallmap the devs are still keeping that field so I guess I'd need to revert that change too in order to get smallmap-zoom accepted. There hasn't been a comment about that, though.

[HackaLittleBit]

Thanks Albert

[petert]

Thanks Albert

Zoom-out is in trunk, but zoom-in is not yet.

[Wasila]

Used to zooming now (CargoDist) and couldn't imagine life without it. Good work!

[fonso]

Well, there is an implementation of smallmap-zoom-out in trunk now. Unfortunately that's not in any way similar to my implementation and it isn't easily extendable to also allow zooming in. Zooming in, however, is the main feature we need for cargodist. Alberth, you could have at least kept the usage of general ScaleByZoom functions. Is that 6x zoom level really important enough to rewrite those? I think you have reinvented the wheel there. Btw, I have gone to great lengths to always keep my implementation in sync with your changes. The last time I have merged them was on Saturday morning, about two hours before you committed your version of zoom out. Oh, what a pain ...

[fonso]

Also, instead of antialiasing you're always doing a full search over all tiles in order to find the most important one. I can't test it right now, but have you tried doing that on a 2048x2048 map in 8x zoom out? I guess it will hang the game for seconds on each redraw.

[Alberth]

Hello Fonso,

The devs are still pondering if it's appropriate to use the ZoomLevel enum for the smallmap. ZoomLevels was invented for the main viewport and some other code doesn't expect zoom-in levels. This is why I had to change some otherwise unrelated code in order to make zoom-in work. Some people don't like that. Others say zoom-in is unneeded.

These are two different, and unrelated things.

Re-use of blitter zoom levels at the smallmap creates a connection between unrelated code. It would introduce weird restrictions at the blitter and/or the smallmap side.

With respect to zoom-in, the step from most zoomed-in smallmap to most zoomed-out viewport doesn't seem very big, thus adding zoom-in to the map would duplicate viewport functionality.

And the main viewport should eventually support zoom-in, too.

Perhaps, one day it will. But such decisions are graphics and/or hardware based, not based on smallmap.

So I'd keep it as it is, but if it helps to get the patch accepted I'll change it to whatever a consensus among the devs says.

There is only one form of consensus and that is 'all devs must be happy with the patch'. That holds for *all* patches going in trunk, who developed the patch is not relevant.

However, even after numerous changes to the smallmap the devs are still keeping that field so I guess I'd need to revert that change too in order to get smallmap-zoom accepted. There hasn't been a comment about that, though.

Why would there be? It does in-tile positioning.

Alberth, you could have at least kept the usage of general ScaleByZoom functions.

I would not have been happy with that weird (in my view) connection. Other dev(s?) would not be happy. Did I mention that *all* devs must be happy for *all* patches going to trunk?
(yes, I have commit access, but that is just about the only difference.)

Is that 6x zoom level really important enough to rewrite those? I think you have reinvented the wheel there.

Perhaps, but not making that connection with the blitter zoom gave me the freedom to add that zoom level.

The last time I have merged them was on Saturday morning, about two hours before you committed your version of zoom out. Oh, what a pain ...

Sorry for that.

Update: Changes are not finished yet, it seems. Computations are not stable

[Dimme]

With respect to zoom-in, the step from most zoomed-in smallmap to most zoomed-out viewport doesn't seem very big, thus adding zoom-in to the map would duplicate viewport functionality.

I think this argument is valid as long as cargodist is not in trunk. If the linkgraph view should make it to trunk, zoom-in is needed, imho. But I guess you either know that and concluded on leaving it for now, or have some clever idea to get around it? I'm really happy every time a piece of cargodist makes it to trunk btw

[Alberth]

I think this argument is valid as long as cargodist is not in trunk. If the linkgraph view should make it to trunk, zoom-in is needed, imho.

If you add a linkgraph to trunk, yes you'd need some form of overview window, like provided with the smallmap zoom-in in cargodist.
I don't know how that linkedgraph is used, but as outsider, it looks mighty complicated.

Is cargodist playable without using linkedgraph?
(/me makes note to try cargodist one day.)

But I guess you either know that and concluded on leaving it for now, or have some clever idea to get around it?

I didn't even consider it. It can easily take a year or longer before some cargod*st variant hits trunk, so preparing for it now seems a bit premature. When it hits trunk, the linkedgraph may have disappeared or changed to some other form.
Also, the smallmap may change in some currently unknown direction.

Let's first see what happens.

[Wasila]

I am an avid CargoDist user and the linkgraph is not integral but without it you are 'blind' as you cannot see which routes are which, the numbers being sent per month on each route and how many people are coming to that station a month (actually, being able to see the numbers being generated at a station each month would be useful without CargoDist...)

[fonso]

I already have a half working implementation of zoom-in based on the new zoom-out. I might be able to finish it tomorrow.

Alberth: Is the instability you mention about RemapTile and vehicles being drawn one pixel off?

[Dimme]

I think this argument is valid as long as cargodist is not in trunk. If the linkgraph view should make it to trunk, zoom-in is needed, imho.

If you add a linkgraph to trunk, yes you'd need some form of overview window, like provided with the smallmap zoom-in in cargodist.
I don't know how that linkedgraph is used, but as outsider, it looks mighty complicated.

I'd say it's hardly one of the more complicated elements of ottd. It simply shows capacity and (planned) usage for each link, so you can quickly find bottlenecks. I think it is quite fascinating to get a grasp of the entire network in one view.

Is cargodist playable without using linkedgraph?
(/me makes note to try cargodist one day.)

Yeah, but as Wasila said, it helps you a lot. Please try it, I think it works much better than cargodest when it comes to dividing cargo between several paths. The other major improvement from cargodest is the linkgraph. Both improvements are more important to the player than one could imagine.

[Alberth]

I already have a half working implementation of zoom-in based on the new zoom-out. I might be able to finish it tomorrow.

Alberth: Is the instability you mention about RemapTile and vehicles being drawn one pixel off?

No, clicking 'center on viewport' more than once shifts the view by one or so pixels.
It may all be related though.