OpenGFX Extra Zoom

[Digitalfox]

I hadn't had the time to try this, but now that I did, I have to say the sprites look really good!

I think all this sprites should be part of OpenGFX 8bpp base set!

[Zephyris]

All the coast sprites are drawn, I thought I had coded them but looks like I messed up!

In general I have no plans, but it would be cool to have a full extra zoom level OpenGFX... At the moment I am just scaling up sprites that really bug me when I play with OpenGFX at extra zoom levels, or are easy to make!

[planetmaker]

All the coast sprites are drawn, I thought I had coded them but looks like I messed up!

In general I have no plans, but it would be cool to have a full extra zoom level OpenGFX... At the moment I am just scaling up sprites that really bug me when I play with OpenGFX at extra zoom levels, or are easy to make!

There are two places where coast sprites are added. The most important one is in the extra grf which has more coast tiles than in the base grf.

I didn't see any commit yet

[Zephyris]

I didn't know there was a repo! Or should I just push them to OpenGFX? It will be a 500mb commit if I include the full source files...

[planetmaker]

I didn't know there was a repo! Or should I just push them to OpenGFX? It will be a 500mb commit if I include the full source files...

There's no separate repo (yet). Do you think it would be better to create a separate one?

[Digitalfox]

Ok, while I think at this point most users that read some of my posts might think I'm some 32bpp or X-Zooms fanatic, I have to say that I'll bite my tongue and say that from all sprites available with X-Zooms available this seems to be the best landscape ones, and I'll probably choose them for my games. Well done Zephyris

But like zBase and others similar set's available, there's a lot of alignment/size bugs on terrain.

Like this:


I tried sprite aligner, but couldn't figure what's wrong since moving the coal sprites didn't fix the alignment bugs it just made better on one side and worst on other.

Could it be that like in zBase the size of terrain sprites is somehow to little by a few pixels?

I could never pinpoint exactly why this happens on zBase:

[planetmaker]

But like zBase and others similar set's available, there's a lot of alignment/size bugs on terrain.

That's a bug with zBase landscape sprites. They're slightly too small, having (semi)-transparency at their edges where they should be opaque. But that's a bit off-topic in this thread and better discussed in the relevant one(s).

[Zephyris]

The issues in zBase and these extra zoom sprites are different... In zBase the tile boundaries are anti aliased, but the alpha where the tiles meet doesn't quite sum to 1 so you get some marks between the tiles.

With these 8bpp extra zoom sprites it is just an issue of tile size. The edges of the extra zoom sprites are accurate (they are identical to the boundaries of 4 or 16 normal zoom tiles arranged into the required shape. The problem is that, for the flat tile, it is z*64px wide and z*32-1px tall, but tiled at a 64 by 32 pitch. That will always leave a large gap when tiling a normal zoom next to a high zoom tile. I did design alternative versions which tile perfectly with the normal zoom sprites, but it lead to very jagged boundaries on slope changes...

[Digitalfox]

But like zBase and others similar set's available, there's a lot of alignment/size bugs on terrain.

That's a bug with zBase landscape sprites. They're slightly too small, having (semi)-transparency at their edges where they should be opaque. But that's a bit off-topic in this thread and better discussed in the relevant one(s).

Ok thanks for explaining!

No, no, I only refer to zBase so it doesn't happen again

The issues in zBase and these extra zoom sprites are different... In zBase the tile boundaries are anti aliased, but the alpha where the tiles meet doesn't quite sum to 1 so you get some marks between the tiles.

With these 8bpp extra zoom sprites it is just an issue of tile size. The edges of the extra zoom sprites are accurate (they are identical to the boundaries of 4 or 16 normal zoom tiles arranged into the required shape. The problem is that, for the flat tile, it is z*64px wide and z*32-1px tall, but tiled at a 64 by 32 pitch. That will always leave a large gap when tiling a normal zoom next to a high zoom tile. I did design alternative versions which tile perfectly with the normal zoom sprites, but it lead to very jagged boundaries on slope changes...

Ok I'll leave it up to you to choose the best solution

[TadeuszD]

The issues in zBase and these extra zoom sprites are different... In zBase the tile boundaries are anti aliased, but the alpha where the tiles meet doesn't quite sum to 1 so you get some marks between the tiles.

With these 8bpp extra zoom sprites it is just an issue of tile size. The edges of the extra zoom sprites are accurate (they are identical to the boundaries of 4 or 16 normal zoom tiles arranged into the required shape. The problem is that, for the flat tile, it is z*64px wide and z*32-1px tall, but tiled at a 64 by 32 pitch. That will always leave a large gap when tiling a normal zoom next to a high zoom tile. I did design alternative versions which tile perfectly with the normal zoom sprites, but it lead to very jagged boundaries on slope changes...

Problem with antialiased boundaries are known and it is one case.
Problem with misaligned tiles is the second case. I reported this problem one year ago in another thread. Please read my post:
https://www.tt-forums.net/viewtopic.php? ... 9#p1083334

I suppose that 4X 8bpp OGFX sprites use the same x-offset from Z-Base. This causes the 4X tiles are shifted left 3px compared to resized 1X tiles.
This is the reason, that the gap on the left side of coal mine is wider than the gap on the right side - see Digitalfox's screenshot:

[Zephyris]

Thanks for all the info, but I don't quite understand! Am I right thinking that this is an unavoidable bug (without extending the boundaries of the ground tiles) then? Or should I use different offsets for an optimal result? I am currenntly using -32*z+1, would -31*z be better?

[peter1138]

-31 is what the original base set uses, and what all 1x NewGRFs use. Don't confuse this as -32+1 (and by extension -128+1), as there is no logical reason for the ±1. Therefore, the only correct offset for 4x to match original 1x is -124. -127 is a nonsense value that sounds right based on the bogus ±1 stuff.

Of course, if you could start out afresh, I would recommend using -32/-128 as offsets. (Probably someone will now explain the original ±1 reasoning...)

[TadeuszD]

Am I right thinking that this is an unavoidable bug (without extending the boundaries of the ground tiles) then? Or should I use different offsets for an optimal result? I am currenntly using -32*z+1, would -31*z be better?

I think you should position 4X 8bpp sprites in the exactly same way how OTTD positions resized four times 1X sprites. Instead xoffset = -32*z+1 you should simply use xoffset = -31*z.
Many existing vehicle and building sets are positioned according to 1X sprites. If you keep 3px offset, those sets will look like misaligned in 4X zoom.

[TadeuszD]

I found next reason why the strange 3px offset should be removed.
On the screenshot you can see set of small triangles. Those glitches appears because the background sprite (derived from base set) from closer tile covers the background sprite (or background child sprite) from neighboring tile (top left).
Those triangles are exactly 3px wide...

[Zephyris]

I've tried the extra zoom sprites with an x offset of multiples of - 31 which seemed to work nicely. Next up, y offsets. With a y offset of zero for the ground tiles you get gaps on the lower edges of the tile, but not at the top. Setting the 4x zoom y offset to - 1 improves this by making a small (1px) gap at the top and a slightly larger gap (2px) at the bottom... Is that a good idea?

Another question, is it documented which pixels are used in the downscaling of the 1x zoom sprites when zooming out? I would like to know so I can write some scripts that ensure those pixels have a sensible value to keep the zoomed out view as clear as possible...

[TadeuszD]

Next up, y offsets. With a y offset of zero for the ground tiles you get gaps on the lower edges of the tile, but not at the top. Setting the 4x zoom y offset to - 1 improves this by making a small (1px) gap at the top and a slightly larger gap (2px) at the bottom... Is that a good idea?

It looks like a good idea, but it is not... You will receive the same effect as shown on my next screenshot. I used OTTD Sprite aligner to simulate it. Moving up the sprite causes glitches on three neighboring tiles: top-left, top and top-right.
The y-offset should be zero.

P.S. The best idea is to use standard base sprite as the ground sprite in building or industry tile spritelayout. It prevents gaps between base sprites. FIRS is a good example. In most cases FIRS industries use standard base sprites (as shown) and additional overlays with roads and building's fundaments.

[Zephyris]

Now with trees (except toyland, palms and cacti).

[Alberth]

Looking good Zephyris!

[V453000 :)]

Very interested to see the results of this

[Auge]

Now with trees (except toyland, palms and cacti).

W.H.O.W!