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

[FooBar]

the new "normal zoom"

Why? Nobody will play the game in zi4 as main zoom level, as a replacement of the normal zoom. It's far too zoomed in for normal use, it's only good for looking pretty. Given the increase of display resolutions, maybe zi2 takes the place of normal zoom as most used zoom level at some point. After all when building something you want an overview of what you're doing while at the same time seeing what you're doing. At zi4 you don't have that overview. Depending on your screen either zi2 or normal zoom will meet both requirements.

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

It's nothing more than overlaying a mask. Something that even can be automated.

[Xotic750]

When I stated the new "normal zoom", I was referring to it being considered that from a graphical/coding perspective rather than a playing/viewing one.

Fair point about an overlay mask, as mentioned I am not very experienced when it comes to graphics and I couldn't think of a way to do it while writing.

Doing this though, I guess that all the extra zoom (normal, 2x and 4x) ground sprites would need to be remade larger and then masked. If they are not made larger by re-rendering then just a scale up could cause some of them to look a bit odd?

[maquinista]

We have lots of sprites done:

1. Farm tiles (9 stages)
2. Ground tiles (bare, grass, two grass stages, bumpy and rock)
3. Road sprites
4. Railway sprites
5. Airport Sprites
6. Some industry tiles
7. Some house tiles

Most of these tiles has two versions: with lines and without them.

There are done a lot of work. IMHO, It's a bad idea to restart all every two years.
This could become Duke Nukem Forever.

[planetmaker]

It has been an issue before, just like the non-flat ground tiles and the funky offsets many of them (still) use.

All argument I ever read here is always like "We've sprites which don't adhere specs, but we want to use them as we're rather lazy and accept glitches instead of making it properly". Well... I usually work by other standards. And if the time and effort spent discussing this, half of those sprites could already be made to fit...

And if the difference line/no line is of an issue: then I say that the sources are insufficient. For those tiles I play with, it's just two button clicks to generate either version (dis-select border. Save-as).

[Alberth]

There are done a lot of work. IMHO, It's a bad idea to restart all every two years.
This could become Duke Nukem Forever.

You have the sources right? Just re-generate the sprites.

[GeekToo]

Thanks for moving this to a separate thread, Jupix.

...
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

Well, it's not a demand of course, just a request. To start a discussion about the standard for zoomed in sprites, before making lots of newgrfs for it and then losing it all again in the future. Better have the discussion now. It certaintly is not laziness. And you say "all existing ground tile". There are none for extra zoom in in trunk format. So before making, let's have a standard with high graphics quality.

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.

Exactly my point. You already invent 15 out of 16 pixels when upscaling from a newgrf not designed for full zoom and it always looks ugly. So why make it the standard?

[GeekToo]

There are done a lot of work. IMHO, It's a bad idea to restart all every two years.
This could become Duke Nukem Forever.

You have the sources right? Just re-generate the sprites.

Bens sources are for 3dsmax, not a package every body has (including me)

[maquinista]

Why don't you try to create some example tiles?

I think that It could be very useful to have some comparative screenshots.

There are done a lot of work. IMHO, It's a bad idea to restart all every two years.
This could become Duke Nukem Forever.

You have the sources right? Just re-generate the sprites.

Not, Sources are not enough for ground tiles.

This is not "push render and get sprites", this needs some manual retouching.

[planetmaker]

Why don't you try to create some example tiles?

As you may or may not have noticed, I posted a graphics file which has the exact tile boundaries...
Just make tiles out of it by changing the background and filling the inner part with something else than white.

[maquinista]

I'm sorry but at this time, I can't do it, I'm occupied with z2 railway tiles.
They are almost finished, but I need a bit more time.

EDIT: This is a preview of railway tiles, slope tiles needs more work:

[Xotic750]

If I can get the template working for trains, so that I can get them finished and in newGRFs then I may try to create some template in blender to simulate the directions of an OTTD view so that we can render materials on it and then cut and paste the appropriate areas into the masks that Planetmaker has provided., thus giving us the correct lighting effects. I don't think just filling the white spaces with a material will look very convincing, of course I may be wrong.

To clarify my earlier posts, I hope I didn't give the impression of being negative, I was just floating my ideas and asking questions at the same time.

[planetmaker]

If I can get the template working for trains, so that I can get them finished and in newGRFs then I may try to create some template in blender to simulate the directions of an OTTD view so that we can render materials on it and then cut and paste the appropriate areas into the masks that Planetmaker has provided., thus giving us the correct lighting effects. I don't think just filling the white spaces with a material will look very convincing, of course I may be wrong.

I think such template will be very helpful and is IMHO basically what is needed to ensure consistency.

What I provided is not a good mask sprite as-is (as it's only the tile highlight border) But one surely can make one from it to aid this purpose quite easily. I might do that another day.

Given such template as you mention, one can take an arbitrary ground surface and put on it any overlay as needed, especially roads and tracks, but also things like river canal and sea shores do work well in such contexts. That's what I employ for the 8bpp sprites; it helped a lot.

[Jupix]

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"

Yes, that is already supposed to be the case. Whether the ottd codebase follows that principle is not very relevant as it is a machine.
The principles of people are more important.

Why? Nobody will play the game in zi4 as main zoom level, as a replacement of the normal zoom. It's far too zoomed in for normal use, it's only good for looking pretty.

That is a rubbish assumption to make.
The whole reason I got infatuated with -EZ in the beginning was that it made playing ottd possible on my 30" TFT. The vanilla game at normal zoom is basically a nightmare to play. A terrible eyestrain, you can't see anything, and the view covers half the map. Of course, these days I don't get to play at all, because I'm here arguing about missing pixels. Life's funny that way.

All argument I ever read here is always like "We've sprites which don't adhere specs, but we want to use them as we're rather lazy and accept glitches instead of making it properly".

I would assume when people make arguments like that they are not trying to be lazy and selfish. They want a machine solution to the problem, not a people solution. Meaning they would like an algoritm to do the work, and not have to work through 500 sprites again by hand.

And if the time and effort spent discussing this, half of those sprites could already be made to fit...

Then why didn't you?

You have the sources right? Just re-generate the sprites.

Sources were only made an official requirement in 2012. In 2012 we have created little to no new content. So for a lot of content there are none. Fortunately, for the ground tiles, there are some. Whether they are sufficient is out of my area of expertise

Also:

This is not "push render and get sprites", this needs some manual retouching.

This is 100% correct and also stands for these sprites in particular; I've heard it from Ben personally.

[FooBar]

Why? Nobody will play the game in zi4 as main zoom level, as a replacement of the normal zoom. It's far too zoomed in for normal use, it's only good for looking pretty.

That is a rubbish assumption to make.
The whole reason I got infatuated with -EZ in the beginning was that it made playing ottd possible on my 30" TFT. The vanilla game at normal zoom is basically a nightmare to play. A terrible eyestrain, you can't see anything, and the view covers half the map.

Please also read back on what I said on zi2. Normal zoom IMO is what people mostly use while playing. I have a hard time believing that is zi4, however a preference of zi2 over 0z is completely understandable. Hence my conclusion that zi4 is for watching the game, not playing it.

[Alberth]

What I provided is not a good mask sprite as-is (as it's only the tile highlight border) But one surely can make one from it to aid this purpose quite easily.

I got bored writing C++ code, so I constructed a little Python script

[Lord Aro]

GeekToo requested my opinion on this matter, so here it is, ignoring anything else anyone has said :

- The ground tiles overlap at the edges. We have known that this is a problem for years (several months at least) that would needed to be fixed if ever 32bpp-ez became official. Which it has.
- I am no artist, so I do not know how easy/difficult this is to do, however it may be worth seeing what copying the overlap and pasting it on the other side of the tile (you never know )
- Alternatively, we either have to wait for someone with the artistic skills to modify/redraw the ground tiles
- I'm afraid I don't think that modifying how tiles are currently drawn just to fix some glitchy sprites is worth it. For example, if there was a (standard) NewGRF that was buggy or bent the rules (perhaps by mb ) the source would not be modified for that, it is up the the NewGRF author to fix it, not the developers

Just my 2cc

(I apologise in advance for anything wrong with this post )

[Ben_Robbins_]

Hi, I have been sent this way, and very quickly read over the last 2 pages, so here's a quick comment.

I am extremely happy at the progress of the 32bpp code wise, however I have to agree with the artists consensus that the stepped edging is somewhat stepping back in time. However I am willing to compromise in order to move forward, although in saying that I expect the same. So yes it would be possible to chop and change the ground sprites to fit the new criteria, but they will look comparatively poor, and it will take many days if not a week to do, when something else could be being done. Likewise could we not alter them on a safe assurance that they will become compatible when coders work on it instead?

For the much stated comment 'just rerender' it's not that simple; not by a long shot.

Apologies on my personal lack of process, but I will be back!

[planetmaker]

I really can't follow the reservations here and I have the impression there's still a lot of confusion and mis-understanding present. It reads like
Simple scaling is "wrong" and making up pixels and putting them in different places is "right".

In this posting I try to sum up comments and answers from other developers with their consent in a paraphrased way from a recent conversation.

Hi, I have been sent this way, and very quickly read over the last 2 pages, so here's a quick comment.
I am extremely happy at the progress of the 32bpp code wise, however I have to agree with the artists consensus that the stepped edging is somewhat stepping back in time.

Like you say here, people seem to assume that the graphics quality degrades depending on where the ground tiles are segmented. It has no influence on the possible
detail level whatsoever. It only has an influence on which pixel belongs to which (ground) tile. These graphics have been created in about seven years without
ever getting anywhere glitch free. Thus maybe it's time for those who know the underlying logic of the game to make a decision instead:

Q: Can we zoom ground sprites in world coordinates to allow smoother edges?
A: No, because currently we scale all sprites by repeating every pixel in screen coordinates. If we zoom them along world coordinates then we'd need to do that
everywhere also with buildings. But it will fail if newgrf authors use groundsprites with a bounding box (like isr). So, it cannot be fixed with different zooming.

Q: Can it be fixed by letting the groundtiles overlap more i.e. overlap them by 4 pixels?
A: No, it most probably will fail with the continuation of railtracks. Diagonal tracks would miss neighboured straight track depending on the overlap order.
Further, I do not know how that would turn out with foundations, someone (tm) would have to try it

Q: How do you put eg a border right at the edge of a sprite? (eg a wall around an industry)? always have a few grass pixels between the edge of the
sprite and the wall?
A: Having a small distance (less than a pixel in normal zoom) to the bordering tile of one, two pixels in the 4x zoom doesn't hurt either for 1-tile buildings.
For a building sprite directly on the border one might go for a smoother curve there; but it means accepting that sometimes the other ground tile is drawn over
its lowest pixels at at close zoom-in. But I'd definitely not do it for the ground tile for the reasons given above.

If one is really adamant about pixels, maybe we should drop all zooming in and zooming out as that will lose pixels in some case
Given that for the current 'normal' zoom there is a full set of graphics there is no other option than to drop support for loading
graphics with a higher or lower zoom in level than that.

[Ben_Robbins_]

How does it have no visual impact? I can understand if 2 road pieces run together then the point at which a pixel becomes part of another tile can't be seen, however let's say the road sits next to soil. Then as far as I understand it will be stepped. If this is just not so, then fine, let's move forward.

7 years of moving forward with glitches can be thrown at either camp. Are the graphics being made wrong for the correct code, or the code is correct and graphics wrong. That depends who you ask, and since there was no 'this way' then there was no correct. It was just a case of the person working on the code saying what was possible and what was not.

[FooBar]

I've made a picture of the problem at hand:

spritecomparison.png (879 Bytes) Viewed 3345 times

Blue is the area shared between both sprite sizes/shapes/types/whateveryouwannacallit. Green is additional to that in case of enlarged normal zoom sprites. Red is additional in case of the ideal true zi4 sprites.

Personally I'm starting to think that the game should detect a transition between a true zi4 sprite and an enlarged 0z sprite and handle this transition accordingly by dropping the green pixels or inventing the red ones from the picture above. For best results one may want to shift the relative position of both sprites so that dropping and inventing is done on all sides, leading to less inventing to be done at the 'red' sides. If you get what I mean.

Of course I have no idea how feasible this is to implement. Anyone who takes a good look at the picture above (I recommend zooming in on it) will see that there is no simple solution to our debate at hand. But I think the one thing we all agree on is that jagged edges for zoom sprites or simply ignoring all previous 8bpp sprites are both not the greatest solutions.