News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Improved high stations display (foreground and background)

Started by gauthier, August 15, 2013, 02:36:49 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gauthier

Trying to make "big" stations, I got two problems (windows 7 with makeobj 55, as the link to makeobj 55.2, provided here, is broken, playing with Simutrans 112.4 nightly - r6585 for windows (SDL version)).

First : makeobj doesn't like "frontimage[ * ][0][0][1]" (see attached picture). I don't know why ... that looks silly ... Anyway I replaced this type of frontimage by backimage.

Second : it obviously lead to graphical glitches :


I'm confused since "high" stations look possible :

Ters

Simutrans only support front images one level high, as the message tells you. As I understand it, front images are just a workaround to place images in front of vehicles, and vehicles aren't more than one level high either (usually much less).

The high station you post has likely been carefully crafted so that front and back images join together properly. I imagine that this is easier for standardized layouts than repeated elements that can be combined this way and that, like your station hall.

Getting all images to draw in the correct order is perhaps the biggest problem in the Simutrans renderer. It bogged down my OpenGL renderer rather seriously.

gauthier

QuoteSimutrans only support front images one level high, as the message tells you. As I understand it, front images are just a workaround to place images in front of vehicles, and vehicles aren't more than one level high either (usually much less).
That's the way I understand it too. Anyway, on the picture of my station, it's obvious that backimages placed on tile A are rendered before backimages placed on tile B while tile B is before tile A. I call that a bug, anyway perhaps it's intended ... I don't know much about Simutrans'code.

Ters

There are some cases where Simutrans just gives up. Those are not bugs, but technical limitations. The one I know is related to slopes, which I guess could look a bit like this when some parts of the rearmost image is transparent, but it may be unrelated. The way Simutrans determines how to draw the landscape is unknown to me, too.

prissi

It could be an artefact of the new code, which alaso redraw stuff to the left and front if there are ways below. Does the disappear during fast forward?

Dwachs

Quote from: gauthier on August 15, 2013, 07:34:00 PM
That's the way I understand it too. Anyway, on the picture of my station, it's obvious that backimages placed on tile A are rendered before backimages placed on tile B while tile B is before tile A. I call that a bug, anyway perhaps it's intended ... I don't know much about Simutrans'code.
This should not happen if the backimage is not wider then the tile it is on. Can you upload dat/png/pak?
Parsley, sage, rosemary, and maggikraut.

gauthier

Quote from: prissi on August 15, 2013, 08:44:37 PM
It could be an artefact of the new code, which alaso redraw stuff to the left and front if there are ways below. Does the disappear during fast forward?
Yes, it does. (that's weird lol)

dat, png and paks of this station are here.

gauthier

In fact, height is not the problem ...

EDIT : Maybe it's not the same problem. A frontimage is involved here.

EDIT² : disappears with fast forward too.

prissi

Disappearing with fast forward is a strong indication that the new (improved) drawing code is to blame. However, how I have to look deeper into it.

gauthier

Thanks a lot. I'm looking forward to see this glitch fixed so I can release a complete addon of train stations for pak128.

Dwachs

This glitch is due to the display algorithm:

To draw one station tile it does the following: (vehicles left out)
- draw its background
- draw background of connected tiles in front (south / east)
- draw foreground

The problem in your station is: the roof element that shines through is in the foreground image, whereas the roof that should be painted to hide this element is in the background image. Both things have to be either in the foreground image or both in the background image.

To fix the station you could try to move the top of the roof to the background image. The station is still high enough to not lead to glitches with trains.
Parsley, sage, rosemary, and maggikraut.

gauthier

Quote from: Dwachs on August 31, 2013, 10:58:14 AMThe problem in your station is: the roof element that shines through is in the foreground image
I'm not sure if I have well understood. What do you mean exactly with "foreground image" ? frontimage ?

Dwachs

Sorry, foreground = front image, background = back image.

I think, if put the high roof into the back image then the glitch will disappear, hopefully.
Parsley, sage, rosemary, and maggikraut.

gauthier

QuoteFirst : makeobj doesn't like "frontimage[ * ][0][0][1]" (see attached picture).
It's impossible, makeobj refuses that.

Ters

Quote from: gauthier on August 31, 2013, 05:09:46 PM
It's impossible, makeobj refuses that.
That was the statement for front image, the suggestion was to use back image. I'm not sure that's a valid suggestion, though.

gauthier

Well ... Maybe I'm misunderstanding something. Although, I already put everything in backimage as I can't use frontimage.

Dwachs

#16
You should try to move more pixels to the backimage: in particular the complete roof of the high station building.

Edit: could not pak your image ???

You should try to move the high roof sections of these images

frontimage[0][0][0][0][0]=SNFOSstations3.2.6
frontimage[1][0][0][0][0]=SNFOSstations3.2.7
frontimage[8][0][0][0][0]=SNFOSstations3.5.0
frontimage[9][0][0][0][0]=SNFOSstations3.5.1
frontimage[10][0][0][0][0]=SNFOSstations3.5.2
frontimage[11][0][0][0][0]=SNFOSstations3.5.3
frontimage[12][0][0][0][0]=SNFOSstations3.5.4
frontimage[13][0][0][0][0]=SNFOSstations3.5.5
frontimage[14][0][0][0][0]=SNFOSstations3.5.6
frontimage[15][0][0][0][0]=SNFOSstations3.5.7

into the corresponding backimages.
Parsley, sage, rosemary, and maggikraut.

gauthier

I moved the part of frontimage which was drawn over (a 32px high rectangle on top of it), but it just moved the problem downward. I could move a better shaped part, though this is going really tedious, not only for me but for anyone trying to make high stations. I would do that if there's no other way to fix the glitch but I'd like to know first if coders have found an easy way to do it.

Ters

It seems to me that the only part of the roof structure that needs to be in the front image is the right hand pillar, the crossbeam from it and to slightly beyond the wires and perhaps the lowest part of the vertical beam in the middle. Smoke from the trains might seep through the roof in an odd fashion, though.

greenling

Hello gauthier
The Station looks very good out.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

gauthier

Thanks Greenling. It's really sad to be bothered with this bug.

Quote from: Ters on September 02, 2013, 03:11:06 PM
It seems to me that the only part of the roof structure that needs to be in the front image is the right hand pillar, the crossbeam from it and to slightly beyond the wires and perhaps the lowest part of the vertical beam in the middle. Smoke from the trains might seep through the roof in an odd fashion, though.
Unfortunately, I got back to studies, so I don't have much time to work on this again. I will tell you if there are news about this.

Quote from: prissi on August 26, 2013, 09:01:17 PM
Disappearing with fast forward is a strong indication that the new (improved) drawing code is to blame. However, how I have to look deeper into it.
Why not just using the same drawing code for not-fast-forward mode ?

Ters

Quote from: gauthier on September 17, 2013, 05:33:19 PM
Why not just using the same drawing code for not-fast-forward mode ?

Unless someone has done something really strange, it's because the fast-forward drawing mode sacrifices accuracy for speed. While it makes your station look good on its own, other things (likely vehicles) will be drawn wrong in relation to each other.

gauthier

Quote from: Ters on September 02, 2013, 03:11:06 PM
It seems to me that the only part of the roof structure that needs to be in the front image is the right hand pillar, the crossbeam from it and to slightly beyond the wires and perhaps the lowest part of the vertical beam in the middle. Smoke from the trains might seep through the roof in an odd fashion, though.
Though, even if I'm able to fix the problem with each type of station alone, it would still be a mess if I use different stations together (see attached picture).

I still think there is a problem in the drawing code.
Quoteit's obvious that backimages placed on tile A are rendered before backimages placed on tile B while tile B is before tile A.

Dwachs

#23
? Whats the problem in the picture you posted (besides the filename) ?

Edit:  If the graphics overlaps to neighboring tiles then glitches can appear.
Parsley, sage, rosemary, and maggikraut.

Ters

There are unsolved problems in the drawing code, that is well known. We just haven't figured out how to solve all problems. The odd drawing algorithm causing problems here is likely to solve another problem.

gauthier

Quote from: Dwachs on September 19, 2013, 04:47:06 PM
? Whats the problem in the picture you posted (besides the filename) ?

Edit:  If the graphics overlaps to neighboring tiles then glitches can appear.

Fabio

Couldn't front images be allowed also for a second tile height?
Would it cause worse glitches?

I'm experimenting a new station concept:

Here all roof is painted in a higher tile and then lowered with offsets. Thus, hiding buildings (normal or smart hiding) will hide the roof showing what's below. It might allow better results with non transparent roofs.
Also I believed that the upper tile background is painted above the lower tile foreground (and vehicles, of course!), but apparently it's not that way. :-[

Dwachs

The drawing order on one tile is: all backimages, then all front images.
Parsley, sage, rosemary, and maggikraut.

Fabio


Ters

For what? Front images are there to appear in front of vehicles. Do you have multistory vehicles?

Fabio

Quote from: Ters on October 17, 2013, 03:02:07 PM
For what? Front images are there to appear in front of vehicles. Do you have multistory vehicles?

See:
Quote from: Fabio on October 17, 2013, 11:34:42 AM
I'm experimenting a new station concept:

Here all roof is painted in a higher tile and then lowered with offsets. Thus, hiding buildings (normal or smart hiding) will hide the roof showing what's below. It might allow better results with non transparent roofs.

Dwachs

This picture does not tell much? What are you trying to say?
Parsley, sage, rosemary, and maggikraut.

VS

Fabio wants a station that "opens its roof" when you hide buildings. Since that works by hiding images higher than ground level, he put roofs into that second level.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Ters

That's in serious risk of running into all kinds of problems. Higher level images are assumed to be higher level. If there aren't features based on such assumptions now, there might be in the future. It's certainly an assumptions in my not so successful attempts at hardware rendering.

gauthier

Quote from: Dwachs on October 17, 2013, 11:51:41 AM
The drawing order on one tile is: all backimages, then all front images.
That's the point.
Drawing backimage then frontimage for each tile individually (and then, draw tiles from north-west to south-east) would be more appropriate and would solve the problem.

By the way, see the attached picture : there are also problems involving other structures (bridges here).

prissi

This cannot be solved, since the pillar and the station are on the same tile. Simutrans could only forbid to build that.

gauthier

Quote from: prissi on October 21, 2013, 07:38:33 PM
This cannot be solved, since the pillar and the station are on the same tile. Simutrans could only forbid to build that.
Eeer ... no, they are not on the same tile. The station is on a tile before pillar's one.

Dwachs

Quote from: gauthier on October 21, 2013, 07:32:13 PM
By the way, see the attached picture : there are also problems involving other structures (bridges here).
This is a limitation of the pillar graphics system: you cannot have pillars that have graphics left and right of the track on the same tile. For asymmetric-pillars, all the graphics of the pillar has to be in front of the tracks.

The 'bug' in this post
http://forum.simutrans.com/index.php?topic=12363.msg125195#msg125195
is a glitch in the graphics itself. You cannot expect that a station building overlaps another building that is in front of the first one.

Edit: regarding the original extension request. As the original problem is that  the front image contains too much stuff, the bug will not disappear if higher front images would be possible and more could be put into front images, it would only get worse.
Parsley, sage, rosemary, and maggikraut.

gauthier

QuoteThe 'bug' in this post
http://forum.simutrans.com/index.php?topic=12363.msg125195#msg125195
is a glitch in the graphics itself. You cannot expect that a station building overlaps another building that is in front of the first one.
I don't understand what is exactly your point here. Could you explain please ?

Dwachs

Quote from: gauthier on December 19, 2013, 07:47:20 PM
I don't understand what is exactly your point here. Could you explain please ?
Hm. Maybe this is because I did not understood what actually is the bug there. Could you please explain what you expect to see there?
Parsley, sage, rosemary, and maggikraut.

gauthier

bridge (the bridge itself, its pillar aren't involved here) is on a tile which is "farther" (north-westward) from the player than the tile which has the station on it. I expect to see the station being displayed before the bridge, but it's not.

As far as I understood, the current drawing system draws all back images, then all front images. Maybe this is nice in theory, surely it leads to graphical glitches like the ones I posted here.

I suggest(ed) two solutions :
_ draw back image, then front image, of each tile individually. If this solution doesn't work, tell me why so I can think to another solution.
_ use the same drawing system as the one which works during fast forward and which doesn't lead to the graphical glitches I posted. (maybe it's the same solution as above ?). I would also like you to tell why this solution can't be implemented.

You told me it is a problem in my graphics, so attached a picture with the same glitch, with a station from the official pak128.

Ters

Quote from: gauthier on December 20, 2013, 09:00:03 PM
As far as I understood, the current drawing system draws all back images, then all front images.

No it doesn't, because that won't work at all. There is some other algorithm at play, which I can only assume has been made to solve a problem. But the pillar problem exists regardless of that: it can't be both in front of and behind vehicles. The only solution for that is to give pillars backimages and frontimages. This would likely solve this station problem as well.

Dwachs

gauthier, I meant this post:
http://forum.simutrans.com/index.php?topic=12363.msg125195#msg125195
Something with stations.

The bridge problem is sort of known, it has to do with the fact that bridge pillars only have either front or back images.

Quote from: gauthier on December 20, 2013, 09:00:03 PM
As far as I understood, the current drawing system draws all back images, then all front images. Maybe this is nice in theory, surely it leads to graphical glitches like the ones I posted here.

I suggest(ed) two solutions :
_ draw back image, then front image, of each tile individually. If this solution doesn't work, tell me why so I can think to another solution.
_ use the same drawing system as the one which works during fast forward and which doesn't lead to the graphical glitches I posted. (maybe it's the same solution as above ?). I would also like you to tell why this solution can't be implemented.

The drawing algorithm does the following. Consider this situation

W   N
  X
S    E

When drawing tile X it does:
(1) draw background of neighbour tiles W and N, but only those pixels that are over the tile X
(2) draw background images of objects on X, but only those pixels that are over the tile X
(3) draw background images of neighbour tiles S and E, but only those pixels that are over the tile X
(4) draw vehicles in a certain way (does not apply here), but only those pixels that are over the tile X
(5) draw complete front images of tile X

Of course, this algorithm still has problems: long vehicles on crossings; problems with pillars of elevated ways; problems with pedestrians, buses and trams on one tile; airplanes over bridges; maybe more.

The original glitch (first post) is due to the steps (3) and (5): there are pixels in the front image on X that are supposed to be overdrawn by pixels in front images of tiles S/E, which does not work. Hence my advise to put as much of the image into the back image.

Your suggestion seems to be to use the same algorithm as is used in fast-forward mode. This would be: draw back images on tile X, then all front images (steps (1) and (3) left out). However, this algorithm produces a lot of glitches with long vehicles. It is the same algorithm used in versions before 110.0. I think you can force simutrans to use this algorithm with changing some settings.
Parsley, sage, rosemary, and maggikraut.

gauthier

Quote from: Dwachs on December 21, 2013, 07:35:21 PM
gauthier, I meant this post:
http://forum.simutrans.com/index.php?topic=12363.msg125195#msg125195
Something with stations.

The bridge problem is sort of known, it has to do with the fact that bridge pillars only have either front or back images.

The drawing algorithm does the following. Consider this situation

W   N
  X
S    E

When drawing tile X it does:
(1) draw background of neighbour tiles W and N, but only those pixels that are over the tile X
(2) draw background images of objects on X, but only those pixels that are over the tile X
(3) draw background images of neighbour tiles S and E, but only those pixels that are over the tile X
(4) draw vehicles in a certain way (does not apply here), but only those pixels that are over the tile X
(5) draw complete front images of tile X

Of course, this algorithm still has problems: long vehicles on crossings; problems with pillars of elevated ways; problems with pedestrians, buses and trams on one tile; airplanes over bridges; maybe more.

The original glitch (first post) is due to the steps (3) and (5): there are pixels in the front image on X that are supposed to be overdrawn by pixels in front images of tiles S/E, which does not work. Hence my advise to put as much of the image into the back image.

Your suggestion seems to be to use the same algorithm as is used in fast-forward mode. This would be: draw back images on tile X, then all front images (steps (1) and (3) left out). However, this algorithm produces a lot of glitches with long vehicles. It is the same algorithm used in versions before 110.0. I think you can force simutrans to use this algorithm with changing some settings.
Well, at least we finally got to understand each other :) . Thus I have a much better view on the problem. I'm going to try some changes on my stations and tell you about the results.

gauthier

Hi again.

After some attempts to fix this glitch from the source images, I am finally unable to solve the problem with more-than-one-square-high stations, anyway I solved the other glitches as you can see in the three first following pictures (2 linked and 1 attached).

Another problem : fixing these (by moving the shelter formerly in backimage into frontimage), a glitch with smokes appeared (see the second attached picture). I also noticed other glitches which seem to have the same cause (see the two next and last attached pictures)

I thought about the drawing algorithm and came up with a simple idea. In spite of my programming skills, I still never worked around with Simutrans'code and I have very few experience with C++, so perhaps this idea is stupid ... anyway :

I noticed two facts :
_ The program is able to do some carving in images ("(1) draw background of neighbour tiles W and N, but only those pixels that are over the tile X") - yes it can be obvious for you, but not for me :p
_ With a very simple algorithm like I proposed earlier (Drawing backimage then frontimage for each tile individually (and then, draw tiles from north-west to south-east), drawing everything in the right order on each tile), all should work nice (if not, please give me an example) until vehicles come as they are often over two (ore more) tiles at the same time.

My idea consists in drawing everything like said in the previous point except for when it comes to drawing vehicles. At this moment, doing some carving with the vehicles (draw only the part of the vehicle which is over a tile on this tile) should prevent glitches from displaying.

To sum up :
On each tile, from the top left (or right ... as you wish) one to the bottom right (or left) one on the screen, and eventually lower than the bottom of the screen for high buildings located there :
1) draw the terrain if necessary
2) draw the way if there's one
3) draw backimages (signal, station, or whatever, or simple building)
4) draw vehicles : only the part that are on the tile (it's probably a little performance-saving to say only the part below the two top lines of the tile)
5) draw vehicles'smoke : [...]
5) draw frontimages ([...])
6) did I forget anything ?

Last : the pictures :




Ters

Quote from: gauthier on August 30, 2014, 09:12:34 PM
6) did I forget anything ?

What's the performance hit of doing the rendering more complex?

gauthier

Quote(it's probably a little performance-saving to say only the part below the two top lines of the tile)
That implies a little less image carving than "the part on the tile", though not a big deal. Parts under the tile limit would be overdrawn by next tiles, so there's no need to carve it. That's what I'm saying. I did not compare performance of this algorithm to that of the current drawing algorithm (and I have no idea which one would be the best regarding performance).

Anyway, thinking about that last night, I just realized there's a glitch in what I said, backimage of a tile would draw on a small part of vehicle placed on this tile and the tile behind. Would it be possible to carve parts of vehicles over the backimages of a tile instead of over the tile itself ?