32bpp - Grf Required to Alter Sprites Order of Appearance

[DaleStan]

Due to level crossings not being a possibility on an embanked slope in OTTD,

When did I say "slope"? This happens on flat land too. It also (I believe) only happens in certain town zones, but I don't know/recall which ones. If you just get the crossbuck, you're in the wrong zone; you need the red and white gates.

[prissi]

My 2 cent: I think it would be much much better to have roads seperated from the ground. This way, one could change the ground without changing roads/tracks/etc each time. Especially, when there are more than one type of ways for each category this is much of an improvement.

[Alltaken]

yes it would be a massive improvement.

[ZxBiohazardZx]

My 2 cent: I think it would be much much better to have roads seperated from the ground. This way, one could change the ground without changing roads/tracks/etc each time. Especially, when there are more than one type of ways for each category this is much of an improvement.

still should be impossible to up land when a road is over it;)

[Ben_Robbins_]

DaleStan: Not saying you did. I was saying it is separate to what I spoke about, and that tile you spoke of cannot appear in the circumstances that I stated. I don't really see the connection between the embankment problem and the level crossing problem though other than that they are both a graphical problem. Part of a ground tile (in this case the level crossing) not getting placed behind a building is partly solvable if the buildings are changed to work like the cinema, which has a large part of the building as the base tile. It won't work for all, and it’s not perfect, but it’s not a completely dead end; the problem is semi solvable.

On the other hand stopping tiles appearing in the wrong order on embankments is graphically unsolvable I believe, and I was hoping switching the order of appearance, or doing something to similar effect would not be a huge request. Suggestions as how to tackle it in itself, or along with other similar problems which you have said about, would be a step in the right direction though…

[DaleStan]

They may be separate problems, but adding the appropriate bounding boxes would fix both of them, unless I'm vastly misunderstanding something.

[Alltaken]

Ben_robbins_

it may be a comprimise that you need to make temporarily, it is a similar issue to vehicle lengths, cutting up tiles....... yes a lot of things could be solved by coders, and i am a fan of that, but planning for the future like you are doing and outputting into the present (temporarily) will ease the process.


Features i would love to be coded, but have comprimised temporarily (but designed my renders to handle it)

1) Transition tiles (snow-grass, desert-grass...) being overlayed in the game
2) vehicles tilting on hills
3) grass tiles having height (yes my original designs did the same, and grew over time)
4)changing the track layout for smooth curves.....


I personally recommend biting the bullet on this one. but keep it in your mind.

My personal plan for rail was to have it "above" the grass, so no dip occured (our railways are all fairly high, likea few meters above ground level normally). however there would be such situations where things would be dipped below it, like canals.... just keep it in mind,a nd when a coding opportunity comes up, give the coders a gentle nudge in the right direction and you will find they are really good.

We have some great coders here, with time as a large constraint.

but again, i do think you are right. i just think that you can turn it into a non-issue with a little tweeking, and come back to it when the time is right.

the order issue could however solve a few other issues though, such as buildings being one sprite perhaps...

Alltaken

[Ben_Robbins_]

DaleStan: Would adding bounding boxes to every single ground tile which exceeds the tile edge not be way more demanding on a computer than just altering the order for the embankment sprites though? I’m aware that it doesn’t tackle both the problems, but as said, I don’t believe the other problem is such a dead end currently.

Alltaken: If it’s a compromise to the extent that we go about this in the same way as the trains, and make them as there intended to be in the future, on the assumption that we are working towards a date where it is possible, then I agree. I can live with the problem however ugly, if I know that in making graphics, I won’t be deleting most of them later, or that the problem is never intended to be solved.

On the other hand, I didn’t see this problem as being similar to things such as additional tiles, transitional tiles, vehicles on a hill, extra angles, smooth curves, 4 seasons, 4 angles, more buildings etc. etc. They all require additional room for sprites, and I assume are quite big jobs. On the other hand, what I was/am asking is that those 2 sets of sprites have the order of appearance switched. This involves no new sprites.
The other key difference with this discussion and those other things is that, apart from vehicle length, there is no barrier currently as a result of them not being available. i.e. Not having 4 seasons available does not mean we can’t make 1 season, and have it work fine now, and we won’t have to remake it later either.

The railway bits I’ve played around with also do not “dip”. They rise above the grass. Dipping would make a bit of a problem as you expose the background, so this should be avoided. It was for this reason that a while ago, I suggested pavements should be raised slightly, rather than none pavement areas being sunk.

In short, I hope this would be a tweak, and not involve a large area of the code being rewritten. Making the problem clear is my “gentle nudge”, and I hope something shall come of it. It would be helpful is some OTTD developers could make it clear what their intentions are though. I would prefer to be making graphics with a goal, however distant, rather than just modeling with no guarantee that I’m not just ‘wasting’ hours time, and I imagine I don’t just speak for myself there.

[Rubidium]

just altering the order for the embankment sprites though?

Am I correct to say that the embankment sprites are the ones used a foundation for roads etc. on non-level areas? If so, you really do not want the foundation sprites to have pixels above the height of the leveled (embanked) tile, because this will show these walls (at least the part above the 'embanked' tile) also when the leveled tiles are neighboured by other leveled tiles.

[boekabart]

I don't agree with 'raising only': If anything is allowed, all should be allowed.
Anyway, please be a little more patient, i'm working on a solution for the whole problem, as described in my previous post (last solution in that post), but I have to mix it in with busy work schedule, so might take a day or two more.

[Ben_Robbins_]

Rubidium: Yes, I mean the foundation pieces when a road sits on a none level area. Although only a minor advantage, it would be nice to be able to bring the wall above the ground height, but I'm aware that it couldn't happen between all the tiles, but that was only a problem for some as I saw it. Although in looking at the sprites in the grf I can only find some of them, and one seems to be duplicated, which leaves me slightly confused.

Boekabart: Ok, noted. Thanks. I think the problem has been discussed/explained in its entirety now, so I'll get on with graphics again.

[boekabart]

Ok here it is. I used Ben's tile for the example, but it would work too with a tile with a 'dip' in it, i'm sure.

Ben, note that the bottom edge of your tile is not 'sharp': it has 'fluffy' alpha which may turn out to be a problem no matter how the drawing will be implemented.

I think Alltaken should invent (or did he already?) a way of rendering tiles so that a flat tile should occupy exactly the pixels of a nominal tile (see last attached png).

Explanation: I cut out a nominal tile from Ben's tile, splitting it up into the nominal part and the 'rest. Note that the bottom edge wasn't sharp, so there is some transparency at the bottom edges.

Then I 'drew' the nominal tiles (png 2). Since they exactly line up (no overlap), the drawing order doesn't matter. You see the little bit of transparency of the bottom edges showing as transparent lines between them.

Then, I blend over the 'outside' parts (png 3). Since also these don't overlap each other, drawing order isn't important.

Then final result is shown in png 4. Note that there are still some darker lines visible. I checked in photoshop, when drawing the original tile top-to-bottom, this also happens: it's a result of rendering a single tile in blender I think.

BoekaBart

[boekabart]

And for the next 2 pictures:

[boekabart]

Isn't it actually an easier solution to take 3x3 of the same tile, render the center sprite and use the above 'mask' to cut it out exactly? Seems to me to be the perfect solution, right? no?

[athanasios]

Side question: Grid lines appear intentionally?

[Leviath.NL]

Side question: Grid lines appear intentionally?

Then final result is shown in png 4. Note that there are still some darker lines visible. I checked in photoshop, when drawing the original tile top-to-bottom, this also happens: it's a result of rendering a single tile in blender I think.

[ZxBiohazardZx]

Ok here it is. I used Ben's tile for the example, but it would work too with a tile with a 'dip' in it, i'm sure.

Ben, note that the bottom edge of your tile is not 'sharp': it has 'fluffy' alpha which may turn out to be a problem no matter how the drawing will be implemented.

I think Alltaken should invent (or did he already?) a way of rendering tiles so that a flat tile should occupy exactly the pixels of a nominal tile (see last attached png).

Explanation: I cut out a nominal tile from Ben's tile, splitting it up into the nominal part and the 'rest. Note that the bottom edge wasn't sharp, so there is some transparency at the bottom edges.

Then I 'drew' the nominal tiles (png 2). Since they exactly line up (no overlap), the drawing order doesn't matter. You see the little bit of transparency of the bottom edges showing as transparent lines between them.

Then, I blend over the 'outside' parts (png 3). Since also these don't overlap each other, drawing order isn't important.

Then final result is shown in png 4. Note that there are still some darker lines visible. I checked in photoshop, when drawing the original tile top-to-bottom, this also happens: it's a result of rendering a single tile in blender I think.

BoekaBart

looks nice but will it work for sloped tiles as well, since i think it wont work:P

[Alltaken]

I think Alltaken should invent (or did he already?) a way of rendering tiles so that a flat tile should occupy exactly the pixels of a nominal tile (see last attached png).

Yep I did

It compleely ignores height of grass though. I figured that the grid lines (which i rather like) would cover up any edges enough to make it not a problem.

Alltaken

[Ben_Robbins_]

The dark lines were intended. There the grid lines. There is grass tiles without these lines in the .blend thread somewhere. The black lines were put on after rendering so making a sprite without them is far easier.

To get rid of the 'none sharp' near side edge the easiest thing to do is just have 3 base tiles left, right and beneath the tile being rendered. Then stick a mask (wich can be the same for all renders) over it to get a clean cut). These rail tiles arn't done yet though, which is why the problem's still there. These are just some test bits.

'Final Result' is correct. Cutting sprites into segments won't be hard to do though, so thats not much of a concern. Speaking from the perspecitive of making graphics, this method would be fine.

ZxBiohazardZx: why wouln't it work for sloped tiles?

[DaleStan]

Because many of the sloped tiles don't independently tessellate without rotation.

IOW: You can't pack nine of the tiles with a single high vertex together into a 3x3 grid without gaps, unless you turn some of them upside down.