How OTTD aligns real sprites for ZOOM 1X, 2X and 4X?

[TadeuszD]

I'm preparing some ZOOM 2X sprites for my set. But I can not find any information, how the ZOOM 2X and 4X sprites should be aligned with base ZOOM 1X sprite? It is important when we mix base and zoomed sprites or sprites from another sets (landscape, vehicles, buildings, etc.).
I see two possibilities - sprites can aligned to upper corner (A) or to lower corner (B) of the theoretical tile. There is 1 pixel difference in sprite offset for ZOOM 2X (Red) in case A and B. The black line is the theoretical tile size and position.

I wouldn't ask how other sets do it. I would ask how the OTTD calculates the position of the tile, vehicle or object sprites for different ZOOMs?

[frosch]

I would think that stuff is aligned on the back corner. You can check in-game whether your ground sprites align with the bounding boxes of builings on the tile: https://secure.openttd.org/wiki/NewGRF_ ... Box_viewer

Note: This only defines an alignment if you use smooth tile edges. If you go for blocky edges, there is no rule which could be deduced from code.

[TadeuszD]

If you go for blocky edges, there is no rule which could be deduced from code.

Are there any rules agreed by the artists and NewGRF coders?

I know developer tools in OTTD, but bounding boxes don't cover ground tiles (the pink square is the flat tile from base OpenGFX set) - it's hard to deduce anything... Maybe it is a bug in OpenGFX sprite offset? I downloaded ZBase for tests and it looks more compatible with bounding boxes.

[planetmaker]

If you go for blocky edges, there is no rule which could be deduced from code.

Are there any rules agreed by the artists and NewGRF coders?

I know developer tools in OTTD, but bounding boxes don't cover ground tiles (the pink square is the flat tile from base OpenGFX set) - it's hard to deduce anything... Maybe it is a bug in OpenGFX sprite offset? I downloaded ZBase for tests and it looks more compatible with bounding boxes.

The offsets for ground tiles are correct. And if you look it up even identical in zBase and OpenGFX as they share the code in that respect. The difference lies only in zBase providing additionally sprites for 32bpp in zoom levels 1x, 2x and 4x.

Being unique in its area might seem a good idea to take zBase as a guide. Yet its ground tiles overlap the actual area a ground tile may cover in some cases which leads to glitches, e.g. at bridge ramps or when mixed with other ground tiles from non-scaled NewGRFs. This fact leaves me hesitant. But it makes seem the bounding boxes seem to fit better.

On another note, a tree's bounding box need not match the ground tile - though it should not move out of it either. Generally it seems that some bounding boxes in OpenGFX can still be improved

In summary: I believe the bounding box you show is quite accurate. Not sure you can make it "fit" better; it's about pixel accuracy scaled by 2x or 4x.

[TadeuszD]

Thank you, planetmaker, for the explanation.
I studied the code of both base sets an I found interesting thing:
In OpenGFX we have:

Code: Select all

template tmpl_level_ground_file(x, y, file) {
    [ x, y, 64, 31, -31,  0, file ]
}

I guess this values (size and offsets) are doubled and quadrupled when OTTD resizes the standard tiles for displaying it in zoom view. The same code is copied into ZBase for standard set of sprites.

In ZBase we have equivalent for 32bpp:

Code: Select all

template tmpl_32bpp_zoom_ground(zoom, file)
 { [0, 0, 64*zoom, 64*zoom, -32*zoom+1, -32*zoom, file] }

Let's compare template parameters:

tile width: 64 vs. 64*zoom (OK)

tile heigh (including y-offset): 31 vs. 64*zoom-32*zoom=32*zoom (ZBase tiles are 1 pixel higher then OpenGFX; I think this is the source of glitches on edges; In my opinion it should be 32*zoom-1)

tile x-offset: -31 vs. -32*zoom+1 (and this is the interesting thing - why the x-offset is -32*zoom+1 instead of simple -31*zoom? If I good understand, we have offset mismatch when standard 8bpp sprites and ZBase ZOOM_X4 sprites are mixed. Standard sprites (resized) are shifted 31*4=124 pixels to the left but ZBase sprites are shifted 32*4-1=127 pixels. 124 != 127)

Could you explain me differences described above?
The expression for calculating tile x-offset for zooms affects all other sets, i.e. trains travelling through this tiles...

[frosch]

Your quoting of numbers reminded me that there is indeed a code reference which can be used to define the alignment of ground sprites.

When using half tile foundations the rail sprites are clipped in the middle. The position where the clipping occurs is coded to happen between pixels -1 and +2 (traditional zoom level) in the horizontal direction: http://hg.openttd.org/openttd/trunk.hg/ ... .cpp#l1994

Generally it seems that the original ground sprites are for some reason one pixel off in the horizontal direction. (offset -31 for width 64). Which can also be seen in your zoom in screenshot of the tree bounding box. Starting from this misalignment everything is build upon it to somewhat match

Anyway, for the extra zoom sprites I think it needs alignment in a way, so that the halftile foundations cut symmetrically.

[zero.eight]

I posted a bug report concerning zBase's offset here: https://dev.openttdcoop.org/issues/4387 + Zephyris' thoughts http://www.tt-forums.net/viewtopic.php? ... 0#p1051543.

It shows that zBase's offsets don't correctly align a (ground)sprite in a tile relative to sprites zoomed by the game (i.e. not provided by NewGRF).

The fix I suggested is to change the template to

Code: Select all

template tmpl_32bpp_zoom_ground(zoom, file) { [0, 0, 64*zoom, 64*zoom, -32*zoom+zoom, -32*zoom-zoom, file] }

which gives the following values for a flat sprite like sprite 3981:

Code: Select all

zoom | x-offset | y-offset
  1        -31  ,  -33
  2        -62  ,  -66
  4       -124  , -132

I didn't test them but they fit with the offsets calculated on the images attached to the bug report.

why the x-offset is -32*zoom+1 instead of simple -31*zoom?

Not sure, but the template can be simplified to

Code: Select all

template tmpl_32bpp_zoom_ground(zoom, file) { [0, 0, 64*zoom, 64*zoom, -31*zoom, -33*zoom, file] }

These are the realsprite definitions I use. The offsets are determined by using the sprite aligner tool and seem to align without major issues:

Code: Select all

sprite_1xi : [0084, 0050, 0064, 0031,   -31,   00]
sprite_2xi : [0084, 0150, 0128, 0063,   -62,  -01]
sprite_4xi : [0084, 0300, 0256, 0127,  -124,  -03]

for this set of smooth edge masks:

markers.png (13.31 KiB) Viewed 4341 times

The x-offsets are the same as the calculated by the template. The y-offsets are different but I they have the same effect. The difference is due to a) sprite cropping. zBase uses square sprites with rows of transparency at the top. nmlc crops out the transparency and modifies the provided offsets. The yellow mask sprites don't have any transparent rows so the offsets aren't modified. b) zBase's sprites are 1px taller than the mask sprites.

The reason for using negative y-offsets for the 2x and 4x sprites is to align the top smooth edge against the bottoms of the two tiles above it. If the tiles above show groundsprites and are zoomed by the game (i.e. not provided by NewGRF), this sprite will overlap their rough edges and not show glitches. If the tiles below are also zoomed by the game, there will be glitches where the game doesn't have any information about which pixels to draw because the jagged top edges of the zoomed sprites don't match the smooth bottom edges of the NewGRF-supplied sprites. There isn't a nice fix for this bottom edge because the sprites of the tiles below will always be drawn over the sprites of the tiles above when they overlap. In simple terms, the alignment produces image B in the OP.

If all of the surrounding tiles are groundsprites provided by NewGRF and cut to the same mask shape, they will join nicely.

I hope that's somewhat helpful.

[TadeuszD]

Generally it seems that the original ground sprites are for some reason one pixel off in the horizontal direction. (offset -31 for width 64). Which can also be seen in your zoom in screenshot of the tree bounding box. Starting from this misalignment everything is build upon it to somewhat match

Anyway, for the extra zoom sprites I think it needs alignment in a way, so that the halftile foundations cut symmetrically.

Thanks for your interest,
I assume that this misalignment (offset -31 instead of -32) is not possible to correct because of historical reason. But it is very important that other sets should use exactly the same offset. It should be clear rules for all zoom levels. If OTTD uses this misalignment for normal sprites for all zoom levels other sets should use it too.

I think, the bounding-boxes visible in debug mode should be displayed with the same misalignment as ground tiles...

[maquinista]

I align my sprites using the Ben Robins sprites as reference.