32bpp - Grf Required to Alter Sprites Order of Appearance

[Ben_Robbins_]

After quite a lot of experimenting with making railway tiles, I have repeatedly met 1 frustrating hurdle. I've tried to work around it, or sacrifice some things (as I said about in the .blend thread), but I think I've hit a brick wall. Any height to objects on any base tile, which makes the tile exceed the tile edge (in a 2d sense), doesn't work due to the tiles order being altered in some circumstances. The ground tiles bounding box is put after the embankment piece in the order, as I have come to understand (after some help!).

In reference to the attached:

Graphics that are originally just 1 ground tile, as in "1", which, for some reason, would look better with depth as in "2", usually just look like "3" when next to each other. But when the more distant tile sits on an embanked tile it sits on top of nearer squares also, thus "4". So, when in game, with an old tile you would get "5", but instead "6" would occur with any new tile, which is given any depth. The problem obviously doesn't exist for sprites of objects, such as buildings, which have 2 sprites or more.

Firstly, would making a newgrf which makes the embankment piece sit on top of the ground tile, and makes the ground tile sit on the same level as normal ground sprites, have any consequences? I can only see advantages by this, but has something important been missed?

Secondly, assuming this would work, would somebody be willing to make a newgrf for the 32bpp project?

[boekabart]

Sorry, no offense, but am I the only one who really doesn't understand what you're asking for? I've read it over and over again... but can't figure it out. Maybe you should rephrase.... Or is it me?

[brupje]

Sorry, no offense, but am I the only one who really doesn't understand what you're asking for? I've read it over and over again... but can't figure it out. Maybe you should rephrase.... Or is it me?

his problem is that sprites in the back are in certain circumstances drawn over sprites in the front. For some reason this doesn't affect current graphics, but does for the new. I don't get why, and if it's intended behaviour or a bug.

[Ben_Robbins_]

The reason it wasn't a problem before is because the ground tiles had no features extruding upwards from them, and outside of the sprites basic area. This was just because they’re so small it wasn't noticeable. As soon as such a feature is needed, such as a tree, the sprite is separately placed on top, so that things may pass behind it.

The examples of things that now have some depth are: The railway itself, the stones which the railway sits on, and then the blades of grass also. All of these rise up from the ground, and therefore in a 2D term, exceed the edges of the tile.

For the purpose of grass/rails and other small things, a slight extrusion adds depth to the sprite, but does not really require being made up of 2 separate sprites I think.

For this reason I came to conclude that the switching of the order that the elements are stacked in. (the embankment piece, and the ground tile) would stop this whole problem. I don't think it’s a bug, as they appear first so that the tiny bit of wall around the back appears behind the main tile, although in saying that, the tiny bit of wall doesn’t overlap any pixels in the originals so that wasn’t a problem, so I'm not shore. (Check C in the attached).

Here’s an example of where the problem is: (attached) It’s subtle in this case, but isn’t always so. In “A” you can see that the more distant tile sits on top of the closer. This creates the thicker black line. In B I have removed it, that’s how it should be, and as I understand it, would be if the order was switched. The wall at “2” then sits above the tile, which allows the wall to rise up over the edge if necessary, which I prefer, but the consequence is that the wall that appears at point “1” would need to go, and appear as it does at point “2”, behind/beneath the grass.

If this problem went away, I think it will be possible to have diagonal rail pieces the same distance apart by using the technique I said about in the .blend thread. Any small features with depth wouldn’t have the problems I’ve listed, and walls could look a little nicer. See threw elements of the railway sprites which are also currently needed (although not visible in the attached) and the exposure of the un-refreshed background image wouldn’t be required to get track pieces to align as well, which is a problem I’m currently having.

[brupje]

So basicly you say, because in the old situation everything was flat, there was no problem. Now we do have pixels rising above the ground, and the order of drawing becomes a problem?

PS. Damn ben, you make some awesome work

[boekabart]

I totally understand the problem now Ground sprites should (in 32bpp) be drawn from top to bottom, not the other way around.

But I recall from my earlier work on a 32bpp patch that you cannot alpha-blend the ground sprites when drawing. I noticed this when I made my first 'smooth zoom' patch where the sprites were 32-bpp downscaled 2x/4x for the normal zoom-out levels. The edges would turn partly transparent of course (75% or 25%), and if drawn like this, also black edges appeared between the tiles. See attached image.

It can be done, though.
1) If you always ADD instead of BLEND ground tiles when not opaque. This will not correctly render your grass, though.
2) If a strict definition is held, as to what area of the tile is fully opaque, and to which direction (up only, for instance) pixels can extend outside of that area.

Bottom line: Every screen pixel should ALWAYS be drawn at least once by a fully opaque pixel. In the attached picture, this doesn't happen and therefore a little bit of black shines through the green.

[Ben_Robbins_]

Brupje: Thanks! And very basically, yes to your shortened description of the problem. But, it’s specifically where the embankment tiles exist. The order of drawing is only a problem in this situation. (Yet to find others).

Boekabart: The dark line in "A" (diagram in my last post), is the soil around the bottom of the grass tile. In this case it’s not the background showing through, although I am familiar with the problem you described, as this does happen. This problem usually is just up to the artist, and just requires making the near edge pixels fully opaque.

In the top diagram beneath, at point 1, there is a small area which I have been forced to remove rail, so that all tiles can align. When I delete neighboring tiles and leave soil, this hole is noticeable. Without making the entire tile like "B" and filling in the hole, as at point 2, this seems impossible to solve though, without switching the order of appearance between the wall/embankment piece and the ground sprite.

In the 2nd diagram, "1" shows how the original sprites would have it appear. In "2" I have added depth to the tiles as I would hope to have it appear, but in "3" you can see what actually happens, the distant track piece appears on top of the other track piece and the wall.

The final image shows the areas on a rail track that then have to be deleted. This is fine as long as another bit of grass or rail track is in front, but as soon as you delete neighboring tiles and leave only soil the problem is very clear, as you have noted in your diagram. (Therefore it’s not ‘fine’) The background colour shows threw, which is black, or a stain of the last image to lie on top of it, (which commonly is white due to the track building tool). Due to much fiddling, in the previous post’s attachment, only point x is really noticeable currently when other railway/grass tiles sit next to the problem tile.

So, what I’m requesting is that when an embankment tile is used, it is just laid on top, just like an electrified railway has the wires for example. The track pieces/road pieces/paved areas etc, would then just render as any other piece would, as a ground tile, rather than late. I have been lead to believe that this is possible with a grf.

(p.s. Please ignore the semi-opaque pixels on the individual tiles, these are very much W.I.P.)

[Alltaken]

you effectively will need to "cut" the tile fronts off for all tiles.

If you give a bit of bleed when rendering (overrun) you should bee able to cut the tile out afterwards so that they fit together perfectly, and you don't notice.

my farm tiles ran into the same problem, which i needed to sort out by doing similar.

I don't think the game was ever intended to actually be played above 128pixels wide (with a scale refactor making buildings seem bigger again) so problems with tiles shouldn't be that noticeable. but then again, all sergej's renders are at 256.

how have simutrans done it?

Alltaken

[Ben_Robbins_]

The size of the tile isn't really relevant. (notice that diagram 2 in my last post is at original scale) For lower zoom levels you can get away without adding any depth to features on the tile, but assuming you still gave them depth the problem would still occur. Chopping fronts then exposes the background as boekabart described.

I have tried (on some tiles) manually removing pixel by pixel so as to keep the maximum amount of pixels, but the problem is still present, so I'm doubtful that adding bleed would have any positive effect on the problem.

If the embankment pieces can just appear in the same way that the electricity wires appear ‘over’ a railway, then all the problems I have encountered so far should go away. So long as there are no other tiles that need to appear underneath a ground sprite in the same area, then this problem should be unique to this situation. (I can’t think of any that do)

[Alltaken]

Chopping fronts then exposes the background as boekabart described.

Are you using a mask to chop the tiles -post render.

if you have photoshop then i can send you the masks to cut these front pixels (and rear pixels for tiles which don't extend higher than the back)

The history pallet in photoshop allows for automated cutting, and thus perfect testelation.

I do agree though, that the embankments should be drawn under the tiles in front. this way we would literally need only 2 embankment sprites (since we could overlap in front as much as we like)

there are however two seperate problems/standards which we are discussing here. Draw order. and sprite height (i.e. do we have it).

Alltaken

[peter1138]

I have been lead to believe that this is possible with a grf.

Well it's not. GRFs can only replace those sprites.

[Ben_Robbins_]

Alltaken: I made masks from the tile sizes you posted a while ago, so that’s not a problem. By the 'exposed front' I was referring to the red areas in Diagram 3, rather than just the tile edge.

peter1138: Ok, that’s a dead end path then. Any suggestions to tackling this problem?

[Alltaken]

My suggestion (not to sound like a broken record) would be to remove the "red things" at the front.

Its really a big toss-up as to the benifits/efforts. i too would love to see height in tiles like you have. but at the same time i don't know if its important.

you can still manage to get the train tracks looking like they have depth compared to the grass. just the tile will be trimmed flat as though there is no depth.

Alltaken

[Ben_Robbins_]

The problem is, that that is exactly what I have done for the track so far. And the track mostly runs together ok. But exposing the background is not the way to go. If I deleted the nearest pieces of track, from each pair, in the image I attached my 2nd post, the scale of the problem would be more apparent and all the red areas in Diagram 3 would be a range of colours as the background showed through.

This problem will exist on anything that is given some height and can sit on an embanked tile. Pavement, Grass, Crops, Stony Areas, Bumpy Areas, cambered road, Airstrips...etc.etc. The problem will keep appearing, so long as modelers add depth.

Cropping all extruding elements of a tile, as in Diagram 1, and 4, looks poor when tiles are together. The illusion of depth within a texture contradicts flat sprite edges, and over all things will look distorted relative, Escher style, so when you move your eye from one bit to another it doesn’t make sense. I am very much against doing that.

I'm now unclear as the effort required to fix this problem, but the benefits would be large.

[DaleStan]

Why is it so hard to just use the current system?

One sprite for the ground, strictly cropped. And one or more sprites for everything above the ground, cropped to stay inside its bounding box, but not necessarily projected on its tile.

The only thing I see changing is that rail and possibly roads will have to be done with two sprites, instead of one. (Stations are already done this way, as are houses, industry tiles, objects, trees, &c.)

[Alltaken]

could you please post a Single tile. i will crop it here.

if done correctly, there should be no background showing through. because cropping it will trim it to Zero alpha, and 100% Alpha with nothing inbetween.

Alltaken

[Ben_Robbins_]

Dalestan: If somebody was willing to do all the coding required to have 1 sprite for the ground element, and 1 for everything above the ground, then that is fine, and would be very much appreciated, but: The problem only exists, as far as I know, on embanked tiles, so why double the sprites for all tiles that are effected by this problem instead of working to fix the cause of the problem?

1) Is there room for this many more sprites currently?
2) Would it be less work, and the “correct” thing to do, for a person to make double the sprites for each tile that exceeds the tile edge, rather than altering the order of appearance for the problem tiles?

Alltaken: Yes, there will be no background showing threw assuming the tile is flat. I can crop a tile, that’s not the problem; the problem is that which I stated above: Flattening does not look good.

[DaleStan]

The problem exists *anywhere* a "flat" tile exceeds its mask. See, for example, what happens to the USSet's level crossings when there's a building to the immediate north. Specifically, the gates end up under the building when they're up. If you want your tracks and roads to have depth, they'll have the same problem, albeit on a smaller scale, even on perfectly flat land.

[boekabart]

As I see it, Ground tiles with 'height' can be done under 2 circumstances:
* At least the 'normal' square should be fully filled with opaqueness, or else holes might appear when tiles-that-are-not-meant-to-be-next-to-each-other are in fact next to each other (eg. end of railway line).
* Drawing order should be fixed. For instance, if we want tiles to be able to 'come up', we should draw the tiles on the screen top-to-bottom. But if we want to allow them to have 'depth', we need to draw them bottom-to-top (as it is now).

A second option is to actually give tile pixels a Z-value somehow (mask), and make a z buffering.

A third option is to split the tiles (at load time?): cut out the 'normal' square as a ground tile, and if there is any rest outside that normal tile, make that into an overlay tile which is drawn in a second pass. That would actually work for both 'height' and 'depth'. Every tile still has to 100% fill the 'normal' square though, to prevent holes. I'll try to make an example mockup of this process this afternoon (CET).

[Ben_Robbins_]

Dalestan: The problem for the USSet's level crossing only exists where a building sits close to the edge of the next tile up. If the building doesn't come to the edge of the tile, and a ground sprite sits beneath it the problem goes away. (e.g. HQ) There are few tiles which have the building go right to the edge. The American football stadium is one example.

So the railway crossing barrier is appearing behind the building, but not behind the ground sprite, which is what I am talking about. Due to level crossings not being a possibility on an embanked slope in OTTD, I can't get this same problem to occur using the USSet level crossing sprites.

I assumed fixing the appearance order of a few sprites would be easier than making additional sprites for all elements of a sprite that go beyond the squares area. The few tiles being the embankment pieces.