Skip to main content ↑ ↓
Topic: [patch] zoom routines  (Read 3531 times) previous topic - next topic

[patch] zoom routines

This patch fixes / does the following:

1) it fixes the bug mentioned here: http://www.simutrans-forum.de/forum/thread.php?threadid=4951, where vertical lines are distorted after zooming

2) it introduces more / other zoom levels:
zoom in: 4:1, 2:1
zoom out: 1:8
It replaces zoom out 2:3, 1:3 by 5:8 and 3:8, where the difference between trunk and patched is hardly noticable. However, this fixes problems with the cursor routines in pak sets, where the tile size was not a multiple of 3.
Parsley, sage, rosemary, and maggikraut.

Re: [patch] zoom routines

Reply #1 –
Does zoom_num refers to the nominator of the zoom level? => zoom_nom + add comment

Why are the first entries 8/2 and not 4/1?

Re: [patch] zoom routines

Reply #2 –
Quote from: gerw – on
Does zoom_num refers to the nominator of the zoom level? => zoom_nom + add comment
yes
Quote
Why are the first entries 8/2 and not 4/1?
Since zoom_nom=1 is not implemented. This would only double the pixels. With 8:2 there is some interpolation going on.
Parsley, sage, rosemary, and maggikraut.
 

Re: [patch] zoom routines

Reply #3 –
Actually the 2x larger and up (which only work with pak32) ones really needs a different algorithm. This was which I left them out initially. Also a zoom level, that does not work with pak64 is imho pretty useless ... (and 4x does not work with 45x45 pixel upwards size).

I agree that 3/4 may go. But I would like to keep the 4/3 level, since the step between 1 and 1,5 is quite large. Maybe one can use 5/4 instead, if really the /3 is to be avoided. But, 96*3/4=128, i.e. much smoother vehicle movements. And a single zoom out level for pak128 is quite a little.

(On a different note, it would be nice, if the additionally zoom level for the minimap could be also set be arrows and not mouse only. A bug I forgot to report for ages.).

Re: [patch] zoom routines

Reply #4 –
I just tried: 4/3 works nice with pak64, so we can keep this.

The main point here is to replace 2:3 and 1:3 by 5:8 and 3:8. Since in the x:3 zoom in pak64 there is an offset between cursor position on screen and on the map, which is really disturbing.

For pak192, I think a zoom out 1:8 is also needed.

And this zoom in 2:1 and 4:1 may be really useless.
Parsley, sage, rosemary, and maggikraut.

Re: [patch] zoom routines

Reply #5 –
IN priciple the relevant structures can be easily extended into sint16 unstead the current mix between unit8 and sint16 (which was only done to fit the structue in a multiple of 32 bytes for being aligned. But this is not important any more I think.) Thus the new zoom levels might be a good time to do some fruther rewriting/profiling (albeit should be not much).

Re: [patch] zoom routines

Reply #6 –
Quote from: prissi – on
IN priciple the relevant structures can be easily extended into sint16 unstead the current mix between unit8 and sint16 (which was only done to fit the structue in a multiple of 32 bytes for being aligned. But this is not important any more I think.) Thus the new zoom levels might be a good time to do some fruther rewriting/profiling (albeit should be not much).
which structure do you mean?

one could also replaces all the cases in rezoom_img by nested for loops.
Parsley, sage, rosemary, and maggikraut.

Re: [patch] zoom routines

Reply #7 –
THe structure which contains the actual images. Those can be changed to accomodate for larger sizes. In simugraph this would be struct imd.

Re: [patch] zoom routines

Reply #8 –
Was there some idea to go for larger sizes by accomodating the structures (and make the new zoom out levels more useful?)

Re: [patch] zoom routines

Reply #9 –
You mean to change width and heigth to 16bit variables? I have no such plans.
Parsley, sage, rosemary, and maggikraut.

Re: [patch] zoom routines

Reply #10 –
Added a diagonal filter to the 2x outzoom to make it look a little less blocky. Any other decendt filter would be out too (see for instance http://www.tt-forums.net/viewtopic.php?f=33&t=28384&hilit=zoom for comparison and code) but would be much more expensive caluclationwise, since this would be heavy float operation. Might be worth a go, who dares?