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

[GeekToo]

There seems to be some mutual misunderstanding.
Let's make clear why I have a problem with the upscaled edges. Look at the attachment. In the trunk tiles, every tile edge would look like the one on the right (outer edges, inner can be fixed).

[Alberth]

If you make the white rectangle a bit smaller, you can have clean edges at the right picture too. Also, in comtigunous tiles, you will not see any edge, which is the majority of the edges, if all is well.


I don't think there is any discussion that 'your side' is not easier. (I don't know about prettier, I cannot oversee where you cannot get around the limitations in ways I said above, or otherwise.)

The problem that worries us deeply however is that by using smooth edges, you literally throw ALL EXISTING NEWGRFs out the window. Given the rate of development of the 32bpp project it is going to be years before you have enough sprites to cover the world. Even then, there are NewGRFs in use that cannot be changed, and the developer has left long ago.

So, one way or another, the sprites have to be made compatible without glitching all over the place. The big question is how to do that. We need a cunning plan for it.

[GeekToo]

If you make the white rectangle a bit smaller, you can have clean edges at the right picture too. Also, in comtigunous tiles, you will not see any edge, which is the majority of the edges, if all is well.

Very true, for the selector it can be solved, the picture was there to clarify a bit for the readers that understand pictures better than talking. For the ground tiles though, they have to connect to the neighbour tile, and there you have the same problem.

The problem that worries us deeply however is that by using smooth edges, you literally throw ALL EXISTING NEWGRFs out the window. Given the rate of development of the 32bpp project it is going to be years before you have enough sprites to cover the world. Even then, there are NewGRFs in use that cannot be changed, and the developer has left long ago.

So, one way or another, the sprites have to be made compatible without glitching all over the place. The big question is how to do that. We need a cunning plan for it.

Indeed, and that was the reason for starting the discussion, to think about the standard/specification of the ez-sprites with maximum graphics quality, without glitches.
You are right about the newgrfs, there will never be a complete set of all zoomed newgrfs.

Let's define a couple of goals, important for both artists and devs:

• no glitches

• high graphics quality

• old newgrf upscaling possible

I've tried to analyze the problem it bit deeper.

In red and black (not filled) the upscaled tiles, in green the more zoomed in version, the blue line would be the ideal line.

The red and black filled areas are the problem areas: missing pixels between upscaled and deepzoom sprites..
Solvable by:
*Allow slight overlap of extra zoomed tiles (the area between purple lines), could lead to other problems, we'll have to find out, but we can experiment in graphics without changing code.
*Programmatically add pixels: difficult, and probably not good looking
*?
*?
Other ideas?

[Varivar]

As an artist, I don't like the idea of jagging the sprite edges of the full zoom sprites. It will look bad if different tiles are adjacent to each other, for example in a city where different buildings sit next to each other.

Idea:
Give each zoomed tile two different tiles: one with smooth (normal) edges, and one with jagged edges. The game will check for each 32bpp zoomed tile if there's a 8bpp tile next to it. If this is the case, it will draw the tile with the jagged edges underneath the smooth tile, thus filling in the empty space between the 8bpp and 32bpp tile.
If the 32bpp tile is not adjacent to a 8bpp tile, it will not use the jagged version and will only draw the 32bpp version.

Not every tile needs its own jagged tile, one jagged tile could be used for different tiles, since the jagged tile is not very visible.


I hope my idea is clear, despite my simple English

[GeekToo]

The idea is very clear, thanks for the contribution. It would be an optimization of the overlapping sprites solution, only do it when it is needed.

But, I am afraid this is complicated to implement in current OTTD design. The modules that do the actual sprite drawing are not aware of the map topography, and the modules that are aware of it, do not know about graphics details like upscaled sprites or native extra zoom sprites, they just order the lower level modules to draw a specific sprite. They dont know that it is different in 8bpp or 32bpp.

So implementing your idea would mean major redesign, if I am correct. Devs, correct me if I am wrong on this, 'cause the basic idea is very nice.

[Yexo]

You are completely correct GeekToo.

[cmoiromain]

I like that idea. You could even develop further, and instead of having to provide new sprites, simply duplicate the not-zoomed sprite under the zoomed one if an unzoomed and zoomed sprite are adjacent.
However the limitation I see to this problem is that checking for every tile if the adjacent tile has zoomed sprites provided would require extra time for the processor, thus slowing down the game. However I have no idea whether it would cause noticeable lag, considering with the current resolutions the number of sprites on a single screen is relatively limited, especially when zoomed in.


EDIT :

Whoops, for some reason I didn't see the last two posts !

Then maybe the game could draw all the unzoomed ground sprites, and then draw the available zoomed ones over these. Again I have no idea how feasible this is, nor how much it would impact the game performance.

[ArmEagle]

I have hardly any knowledge about the game code. Nor do I draw sprites (anymore; not my forte). But maybe I can provide out-of-the-box thinking.

To me it seems clear that it should be attempted to use as smooth an edge as possible.

From the last time I played with the EZ binaries, I recall there to be a special blitter(?) that used some filter to convert non-EZ sprites into higher resolution 'art-style' versions.

I take it from all this discussion that that option is gone now. If that's the case, why not reintroduce it again? What's the problem in converting the used ground sprites 'on the fly' to adhere to the smoother edges?

• Sure, it will take some converting, thus time. But if it caches the resulting sprites that shouldn't be too big an issue. And if it is an issue, then to me it would easily outweigh the graphical issues.
• Choosing that blitter would be up to the player, so normally there would be no performance hit (when not using EZ sprites, or simply not caring).
• 'Only' the ground sprites need converting and you'd simply convert all non-EZ sprites. That way you don't have to know about neighboring tiles.

Edit:
I'm probably wrong on the last point. Are there non-ground sprites that don't have a ground-sprite rendered under them?

[cmoiromain]

I guess that's what Hqx does. Heck, unzoomed sprites might even look good with zoomed ones ! I have no clue about the possible impact on performance though.

[Michi_cc]

I guess that's what Hqx does.

Decide for yourself if the attached screenshot looks good.

-- Michael Lutz

[FooBar]

I much rather see nearest-neighbour enlarged graphics than that. Looks like my glasses are really very dirty

Anyways, would something like below work? This is a normal zoom tile, enlarged 4 times. In order to make it the same size as a 'preferred' zi4 tile, the green pixels are added to it by replicating the pixels that are closest. The red pixels are not drawn.
A similar method can be applied to zi2 sprites and slopes.

Only thing I'm not sure about is if there are ground tiles that have a different shape than a normal ground tile, in which case a predetermined method like this will obviously fail.

[Michi_cc]

Only thing I'm not sure about is if there are ground tiles that have a different shape than a normal ground tile, in which case a predetermined method like this will obviously fail.

Houses, objects, industry tiles, airport tiles and stations can all draw an arbitrary number of sprites, and all of them could possibly have or have not tile borders. There's no way beforehand to know what will be a tile border and what not, and with extended Action 1, a single sprite might even be used more than once, and might only be at a tile border for some of the usages.

-- Michael Lutz

[cmoiromain]

Decide for yourself if the attached screenshot looks good.

Ok, I'm wrong It did look good with quite a few pictures I used (include games, on emulators for example), but I must admit it definitely doesn't work here. However, I'm nos certain I prefer nearest neighbour to this though. In x2 it looks alright, in 4x I generally don't understand what I see, it just looks like a lump of randomly coloured pixels...

[GeekToo]

Ok, I think we've talked enough, let's make some graphics available. That is the one and only goal we all are looking forward to, whether you're dev or artist. We all want nice graphics. Newgrf loading of 32bpp ez-sprites is available now for a couple of months, and all we did is talk, talk and argue. What a shame, and I admit I certainly contributed to that.

So I took a look at the field sprites of Ben Robbins, and judged it with the eyes of the arguments of the devs, and of the artists, and I came to the following conclusions:
1. The sprites are definately too small, leading to glitches in combination with neighbouring newgrf upscaled sprites.
2. Enlarging the sprites with a couple of pixels on the edges, solves the first issue, and as far as I noticed, does not lead to problems with overlaps (basically what I stated before, but real sprites are easier to judge).

To solve problem 1, I created a script to enlarge the sprites with a couple of pixels, I think this is a much better solution than doing it runtime
The script does create a non-jagged edge, but I did not see problems with that so far, so a very limited overlap of tiles may be acceptable.

So it should be a compromise of the issues mentioned above: no glitches in combination with 8bpp newgrfs next to it , and still have nice edges.

I made the script to enlarge the field sprites by a couple of pixels, selected from the rest of the sprite, so it should be matching the colours of the sprites. Then create an nml file out of it, and finally create a newgrf.

Now, I need you to really thoroughly test it (currently only deepest zoom, z0, or zi4 if you want).

The file is available at (is this a good place for upload of test newgrfs, Planetmaker, Ammler?):
http://dev.openttdcoop.org/attachments/ ... 2/test.grf

- Download the file, put it in the newgrf directory of a recent nightly.
- Start the game, newgrf settings, and select the Ben Robbins Field Sprites with lines newgrf.
- Start a new game ( temperate)
-Start looking for glitches on the field/ farm sprite on deepest zoom level. A way to do this is to use the explosion tool, so the 8bpp raw ground sprite will appear, judge glitches at the edges.

[GeekToo]

A screenshot, showing what the test.grf does.

And in fact, I did test it, I don't want you to do the dirty work. It's just I want it to be good, and more people see more, I always could have missed a bug.

Without getting too technical, it would resolve the problem that Planetmaker discovered in this post: http://www.tt-forums.net/viewtopic.php? ... 5#p1002625.

I.e. the sprites are too small, leaving a couple of pixels at the edges that are not redrawn, when combined with a jagged 8bpp sprite as its neighbour. No discussion needed there, some are just too small, period. So I added these pixels in an automated way, taking out the glitches.

The test.grf uses non-jagged edges, which is in fact another point of discussion.

[GeekToo]

The other point of discussion is the edges. See the attachment. The sprites in the old tars, had edges as shown in B.

The standard that trunk-devs now have adopted is the edge shown in A. That is the point where I have problems: it does not look good, too jagged. The standard for 32bpp extra zoom sprites is very new, and in fact changed to this format pending this discussion.
http://www.tt-forums.net/viewtopic.php? ... 1#p1002811
http://www.tt-forums.net/viewtopic.php?f=31&t=59217
http://newgrf-specs.tt-wiki.net/index.p ... oldid=3004

What I proposed a couple of posts above, complete with a drawing, is to use edges like C. That would imply a very limited overlap of tiles, but I don't see glitches appearing there.
And that would be my question to the devs, or anyone knowing the answer: what would be the problem with that?

I know there has been a lot of misunderstanding about what 32bpp can do, but I think I know what the possibilities are. I don't ask for rounded corners, 128 angles for vehicles, 3d viewing of buildings etc. And I am aware of the problems with sprites that have a large overlap, eg giving glitches on uphill tracks, or foundations. But I did not ask for that.

I just asked for a slight overlap, not even extending the jaggedness of the upscaled 8bpp sprites, to have a solution for the glitches, and also for the bad-looking jagged edges.
Some seem to think that every point in the discussion has been made already, but I think this question was not answered yet.

[maquinista]

Most of ground sprites are done or almost done. I think that we don't need these new edges.

Another idea is to keep 32 bpp and 8 bpp OGFX projects in different files.

[FooBar]

I think that we don't need these new edges.

You need new edges either way: either the jagged edge or the overlapping edge. I'm in favour of the latter, as that looks really good in GeekToo's post. Provided it doesn't flicker all over the place of course.

Another idea is to keep 32 bpp and 8 bpp OGFX projects in different files.

Not a bad idea, but that doesn't change anything for the tile issue.

[Jupix]

Another idea is to keep 32 bpp and 8 bpp OGFX projects in different files.

Not going to happen.

Though you can always fork, of course.

But the current arrangement is out of necessity, and realistically cannot really be reversed.

[planetmaker]

Here's a small testgame. I marked three spots with 'here'. They might be interesting to see. It needs temperate grass and road ground tiles mostly

EDIT: slight update