OpenGFX Extra Zoom
Moderator: Graphics Moderators
- Digitalfox
- Chief Executive
- Posts: 708
- Joined: 28 Oct 2004 04:42
- Location: Catch the Fox if you can... Almost 20 years and counting!
Re: OpenGFX Extra Zoom
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!
I think all this sprites should be part of OpenGFX 8bpp base set!
Re: OpenGFX Extra Zoom
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!
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
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: OpenGFX Extra Zoom
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.Zephyris wrote: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!
I didn't see any commit yet
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: OpenGFX Extra Zoom
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
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: OpenGFX Extra Zoom
There's no separate repo (yet). Do you think it would be better to create a separate one?Zephyris wrote: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...
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
- Digitalfox
- Chief Executive
- Posts: 708
- Joined: 28 Oct 2004 04:42
- Location: Catch the Fox if you can... Almost 20 years and counting!
Re: OpenGFX Extra Zoom
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:
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:
- Attachments
-
- Aligment or size.png (222.71 KiB) Viewed 6398 times
-
- zBase.png (423.79 KiB) Viewed 1448 times
-
- zBase2.png (357.8 KiB) Viewed 1448 times
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: OpenGFX Extra Zoom
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).Digitalfox wrote:But like zBase and others similar set's available, there's a lot of alignment/size bugs on terrain.
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: OpenGFX Extra Zoom
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...
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
- Chief Executive
- Posts: 708
- Joined: 28 Oct 2004 04:42
- Location: Catch the Fox if you can... Almost 20 years and counting!
Re: OpenGFX Extra Zoom
Ok thanks for explaining!planetmaker wrote: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).Digitalfox wrote:But like zBase and others similar set's available, there's a lot of alignment/size bugs on terrain.
No, no, I only refer to zBase so it doesn't happen again
Ok I'll leave it up to you to choose the best solutionZephyris wrote: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...
Re: OpenGFX Extra Zoom
Problem with antialiased boundaries are known and it is one case.Zephyris wrote: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 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:
Re: OpenGFX Extra Zoom
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?
Re: OpenGFX Extra Zoom
-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...)
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...)
He's like, some kind of OpenTTD developer.
Re: OpenGFX Extra Zoom
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.Zephyris wrote: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?
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.
Re: OpenGFX Extra Zoom
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...
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...
- Attachments
-
- OGFX-X4-glitches.png (15.77 KiB) Viewed 6056 times
Re: OpenGFX Extra Zoom
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...
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...
Re: OpenGFX Extra Zoom
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.Zephyris wrote: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?
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.
- Attachments
-
- OGFX-X4-glitches2.png (30.06 KiB) Viewed 5980 times
Re: OpenGFX Extra Zoom
Now with trees (except toyland, palms and cacti).
- Attachments
-
- OpenGFX_EZ_Landscape.7z
- (9.22 MiB) Downloaded 131 times
-
- Unnamed, 30th Jan 1950.png (214.86 KiB) Viewed 5901 times
Re: OpenGFX Extra Zoom
Looking good Zephyris!
Being a retired OpenTTD developer does not mean I know what I am doing.
- V453000 :)
- President
- Posts: 946
- Joined: 01 Feb 2011 11:22
- Location: Beer
Re: OpenGFX Extra Zoom
W.H.O.W!Zephyris wrote:Now with trees (except toyland, palms and cacti).
Who is online
Users browsing this forum: No registered users and 80 guests