Adapting "EZ" 32bpp ground sprites for use in OGFX+

[GeekToo]

Please take a look at:
http://www.tt-forums.net/viewtopic.php? ... 2#p1002612

I think it is a good candidate to include: sources included and gpl2, all source included. Ben Robbins is not very active anymore here, but I think it a good idea to submit this set.

I made a script to convert the tar format to nml. But I am not very familiar with nml, so please be suspicious about the nml file I created, I may have to learn a thing or two.

[Leanden]

Am i wrong to think that this is different to the other 32bpp project involving 3D models? Because all of Zephyris' stuff looks no different to the 8bpp graphics at a glance except for better colour depth.

[GeekToo]

Ben Robbins uses 3dmax to create most of his 32bpp graphics. Judging by the sources he provided, he also did that for this set.

[planetmaker]

Please take a look at:
http://www.tt-forums.net/viewtopic.php? ... 2#p1002612

I think it is a good candidate to include: sources included and gpl2, all source included. Ben Robbins is not very active anymore here, but I think it a good idea to submit this set.

I made a script to convert the tar format to nml. But I am not very familiar with nml, so please be suspicious about the nml file I created, I may have to learn a thing or two.

I had a look at those sprites and added them experimentally to ogfx+landscape. These sprites are unfortunately problematic

- they have offsets which don't match a ground tile (see the attached screenshot the small inset on the right: there's space above the tile which does not belong there). Thise could be taken care of by specifying where the sprite is found within the file.
- they do not have the tile border granularity (same mount of steps) which needs be the same as the normal zoom level simply scaled up. This leads to gaps and overprints at borders with other (normal) tiles. See the resulting glitch in the centre of the attached screenshot. All the white dots are parts which have no coverage due to this. Providing all ground sprites with the finer border granularity does not solve it as it will glitch with (all existing) newgrfs which provide ground sprites. Compare the tile border marker in the main screen with the tile border as the sprite in the small inset. They need to match to the (coarse) tile border marker.

[GeekToo]

No, Planetmaker, I think you are wrong on this.
It is not the granularity that is causing this. It is the upscale algorithm that fails to provide enough pixels.

The edges of the ground tiles have to follow a 2 to 1 pattern in resp x and y, and sprites have to cover the edge line
in order to prevent empty pixels, which leads to glitches, like leftovers of selectors.

So a minimal ground tile would be 4 pixels wide, 1 high. Next level would be 8 wide, 3 high. Next 12 wide, 5 high etc.
In a formula: width = n * 4, height = n * 2 - 1 (or = widht/2 -1).

This matches perfectly with the specs on:

http://newgrf-specs.tt-wiki.net/wiki/Re ... zoom_level

normal (normal) 64 x 31 The standard
zo8 8x out 8 x 3 3rd zoomed-out state (maximum zoomed-out)
zo4 4x out 16 x 7 2nd zoomed-out state
zo2 2x out 32 x 15 1st zoomed-out state
zi2 2x in 128 x 63 1st zoomed-in state
zi4 4x in 256 x 127 2nd zoomed-in state (fullly zoomed-in)

Now let's see what happens with the current upscale mechanism:
Take the normal sprite: 64 x 31
Multiply x and y by 2 for zi2: 128 x 62
Multiply x and y by 2 again for zi4: 256 x 124

So after the upscale, the sprite's width is ok, but it is 3 pixels too low according to the spec, and that is the effect that you see here.

I think the spec is fine, it would be silly to force higher zoom sprite to introduce the jaggedness of lower zoom sprites,
apart from the funny way of working it would mean.
so my statement is that the sprites are correct but the upscale mechanism is not, it is not following the specs.

Only way out is to start with the max zoom sprites and downscale, rounding down (floor), or introduce extra pixels in
y direction when upscaling (probably ugly, but that is always the case with simple upscales).

[maquinista]

The sprites are correct.
The only problems are when there are floor tiles without z1 or z0 zoom level.

Also, there are some floor tiles that could give problems, like the z1 railway tiles.

[planetmaker]

Now let's see what happens with the current upscale mechanism:
Take the normal sprite: 64 x 31
Multiply x and y by 2 for zi2: 128 x 62
Multiply x and y by 2 again for zi4: 256 x 124

That exactly is the correct size. With a border zig-zag which is a simple scaling in factors of 2 from normal zoom.

The only problems are when there are floor tiles without z1 or z0 zoom level.

That's why the tiles are NOT correct. You do have to care for this case. For the sake of compatibility with all existing NewGRFs.

If the size shall be different, we automatically go for glitches, something I'd like to avoid.

[GeekToo]

From a graphical point of view, I think it is a very bad idea to use the upscaled edges of normal zoom level for more zoomed in levels.

It creates ugly jagged edges, and also a very awkward way of working for graphics artist. We want to have a 2:1 ratio in x:y. In the ideal world, this would be a perfectly straight line. But our monitors are not perfect, so we have to deal with square, discrete pixels. But to simulate a straight line, you would have to make some steps in pixels, as small as possible for a certain resolution. Every graphics program will use that principle: 2 steps to the right, 1 step up etc. To further improve the edge quality, you could use antialiasing, which is possible in ottd with 32bpp including alpha.

But with an upscaled normal zoomed edge, you would have to create some kind of awkward mask to create a 4:2 pixel ratio, and thus destroying possible anti aliasing.

To make it more clear, I created a small png with edges like you propose, and with edges the sprites use. It may be clear that the small steps are much better.

Your reason for using the zig-zag edge would be to keep compatibility with newgrfs. I'd say, nonsense, there are no extra zoom newgrfs available. For all other newgrfs, they would need to be upscaled, and that will look ugly always. So a simple addition of a few pixels to the upscale mechanism would solve the problem, and keep the problem where it belongs: newgrf failing to provide extra zoom graphics, but please don't bother the sprites intended for extra zooms.

[peter1138]

To further improve the edge quality, you could use antialiasing, which is possible in ottd with 32bpp including alpha.

You can't use anti-aliasing for ground tile edges. Not without overlapping tiles, anyway.

[GeekToo]

To not let this thread derail too much, maybe we should continue this discussion at: http://www.tt-forums.net/viewtopic.php?f=36&t=46675.

Given the drawing order of ground tiles, I still think it is possible to have AA at top left and top right edges of ground tiles, but that is another discussion that I don't want to go into now, AA was just a sidenote, and a detail in comparison to the other point mentioned.

My main concern in my previous post was the jaggedness of the edges (no AA used in that png). If we would not have an implementation of OTTD, how would you design the graphics? In my opinion, certainly not with edges with an 8:4 ratio, but with a 2:1 ratio to have best graphics quality. Then that is the solution we should be aiming at, not sticking to compatibility with newgrfs that have to be upscaled anyway, with a pixelblock of 4x4. That will never look good, so why make it leading?

I created the nfo/nml because I really would like to have these sprites included, and there are hundreds of sprites in this format in excellent graphics quality available, this is just the first set I posted. Having to regenerate all these sprites would really be a setback, that can not be fixed with a script easily.
And why? Just for the sake of compatibility with a solution that will not look good anyway, and will create a more awkward way of working for graphics artists, modifying every rendered sprite to an 8:4 edge.

[maquinista]

IMHO we shouldn't change the basic format of ground tiles.

I know that tiles without extra zoom levels doesn't look well, and have some glitches, but... these tiles doesn't look well at this moment, because they are pixelated.

Also, most of the ground tiles are done or almost done. Modifying all of them would be more work than creating the other (not done) ground tiles.

There too many work done at this moment and We should keep it.

Offtopic: I have seen my own screenshot, and I think that We don't need full new overhead wires supports. We only need new poles, the other parts could be GIMPed easily with good results.

[FooBar]

I'd try and see how the 2:1 with overlapping looks. If it doesn't glitch then go for this. If it does glitch, there's simply no denying the original 8bpp normal zoom sprites and their sizes.

[planetmaker]

I'd try and see how the 2:1 with overlapping looks. If it doesn't glitch then go for this. If it does glitch, there's simply no denying the original 8bpp normal zoom sprites and their sizes.

I mostly see issues with fences and stuff aligned to the borders of tiles. Ignoring that, it is surely bound to give us trouble, making it impossible to create (ground- and building) sprites which use every pixel up to the borders. It will be hard to test every contingency here, but we're at the start and DO have the chance to make it right in the first place. No damage is done *so far*. The further this is taken with ignoring the overlap and disregarding compatibility with normal-zoom sprites, the more work potentially wasted.

[Jupix]

To not let this thread derail too much

Indeed, let's not do that; I spun off the discussion into another topic. This can be merged into the base set thread if/when that becomes prudent.

Not understanding much about the blitter and offsets, I'll offer my layman's opinion:
1. Ben is not completely gone, he's currently on hiatus from OTTD, he will probably be back soon-ish
2. These sprites were painstakingly worked by him over a long period of time, it would be a great loss for both us and him to not get to use them
3. Some modifications are probably possible to make on the graphics, Ben probably has everything he needs to do that, and some sources are already publicly available
4. We should thoroughly investigate the possibility of modifying either the sprites, or the blitter to work with the content, not merely abandon them based on a failed initial prototype, or a hunch
5. The OGFX+ project owners have the final say on what is coded into their set: if they are 100% sure it can't be made to work, then that's that. The content will have to become a NewGRF, unless someone makes an OGFX+ prototype with these graphics that works and proves that it's possible.

[planetmaker]

Thanks for moving this to a separate thread, Jupix.

To illustrate what this is all about, see the attached image. It shows the outline of all possible slopes for ground tiles in the 4x zoom mode.

Geektoo's demand is, that the tile borders become smoother for the zoom-in levels. But that means breaking compatibility with *all* existing ground tiles and possibly causing glitches with anything not desgined for a changed definition of zoomed-in ground tiles. Even when we invent a method within OpenTTD code to make it smoother, it'll mean that we need to "invent" pixels when we have sprites which need scaling up - something which always will cause trouble and which we *will* have and see for years to come, no matter what we do here and now on the ground tiles in the base set.
On the other hand we have the option to just supply sprites for 2x and 4x zoom-in which follow the zig-zag borders as in the attached image and all will be fine.

I do realise that the existing 2x and 4x ground sprites do NOT follow this scaling law. Nor do I have a script at hand to make it so. On the other hand this is not a terrible difficult task to achieve and can even be manually done in a few hours, maybe one or two evenings. But saving us much potential trouble.

If we have the option to do it right, we should do it right. And not do it in a way which has the potential to cause trouble only in order to save us now a tiny amount of work compared to what is ahead of us anyway.

[Xotic750]

Would it not be wise to do it like I am doing with my replacement trains? As in, create a newGRF for each tile that supplies a replacement for both 8bpp and 32bpp and contains normal, 2x and 4x zoom for both types of graphic. Then this could be done 1 tile at a time and you should be free from glitches?

[planetmaker]

Would it not be wise to do it like I am doing with my replacement trains? As in, create a newGRF for each tile that supplies a replacement for both 8bpp and 32bpp and contains normal, 2x and 4x zoom for both types of graphic. Then this could be done 1 tile at a time and you should be free from glitches?

And you do that for every NewGRF-supplied ground sprite ever drawn in every newgrf out there in the wild?

[Xotic750]

No, I was thinking mainly for base sprites. Surely other newGRFs are addons and, like with any software update on any platform, these will become incompatible (or have glitches) and will require an update by the author to bring them into line. I don't think you would want to enforce rules to stop future developments just to save a ground sprite grf that no longer meets the specification of the underlying system, would you?

[planetmaker]

No, I was thinking mainly for base sprites. Surely other newGRFs are addons and, like with any software update on any platform, these will become incompatible (or have glitches) and will require an update by the author to bring them into line. I don't think you would want to enforce rules to stop future developments just to save a ground sprite grf that no longer meets the specification of the underlying system, would you?

Yes, I'm talking about base set sprites. And it's not about stopping future development. It's all about making development such that we don't break backward compatibility needlessly. And there is no need here. It's also not more work. Just different. NewGRFs which follow the specifications do not become incompatible. That's been a long-standing and successful policy.

And exactly: I do not want to *start* ground sprites which do not meet the underlying definition of ground sprite.

[Xotic750]

My opinion would be that as extra zoom (4x) is now part of the trunk, this should become thought of as the new "normal zoom" as more and more graphics or grfs become available, and that if possible the OTTD code should handle this idea as its primary consideration.

I wish I could advise you how to do it, but as I said, this is just be my opinion of how it should be handled. Yes, I guess until the graphics/grfs become available then glitches due to the up scaling of original sprites are inevitable.

I can say, as a not highly experienced graphics creator, that I think that creating high quality sprites (generally rendered) that have to have their edges made jagged to fit original normal zoom sprites that are being scaled up would be a nightmare and it would certainly put me off technically at present.