graphical glitches of the latest releases

[gauthier]

Here is a list of graphical glitches I have noticed to help devloppers

1) Seems to happen with the needs ground property. Here in the meat_packing_plant :


When I delete what is in front of one tile of this industry (if there is something), the glitch disappear on the concerned tile. But it appears again later.
(You can see that the glitch doesn't appear on the north-east tile since I removed some trees in front of it)

2) Tunnels ...


3) After terraforming, there are glitches on the concerned tiles :


4) the eternal bridge glitch ...



That's all I found now, perhaps I will add some others.
Have a nice work dev. team

[Dwachs]

At first: which version did you run? I suppose, you used some nightly...

1) I cannot reproduce this. Does this happen with all building or just with this particular one? I cannot observe any glitches with the meat packing plant.

2) These are infact two errors: one in the code, which shows a vehicle that is in the tunnel, the other one is in the tunnel-pak: there the way graphic is drawn in top of the vehicle (the way has to be drawn in the background-image, it only happens with the tunnel going west).

3) and 4) are actually the same errors. But they are present in 102.2.2 as well, so a did not introduce new glitches here.

Lets see what I can do with 2-4.

[prissi]

3) & 4) are broken ground tiles. Ground tiles (and ways) should never ever go into the front tile, before it or after it, since the order ground tiles are drawn are not guarantied.

[Zeno]

...I cannot observe any glitches with the meat packing plant...

Comparing the picture here with the ones in this thread you can see some areas (to south and west) where ground should be placed. Hope it helps.

[gauthier]

I run 102.3-3151

[Dwachs]

I run 102.3-3151

Could you please re-test the first bug with a newer nightly and pak128 1.4.6? I cant reproduce this one.

[gauthier]

I will try later, impossible to reach the nightly page now 

[Dwachs]

Something is fixed in revisions 3176 & 3177:

3 & 4) completely

2) the bug in the middle picture, left picture: missing train in tunnel mouth is pak an error, right picture: hard to fix.

1) I could not reproduce, maybe you have a broken pak that misses the needs-ground property?

[gauthier]

It's the original pak downloaded on the nightly page ... I'll try with a more recent one.

I found some other minor glitches, I'm going to see if they're still there in the new releases.

[gauthier]

sim-winsdl_2010-04-29_v102.3_r3190.zip 2.53MB
sim-winsdl_2010-04-27_v102.3_r3185.zip 2.53MB
sim-winsdl_2010-04-26_v102.3_r3184.zip 2.53MB
sim-winsdl_2010-04-25_v102.3_r3182.zip 2.53MB
sim-winsdl_2010-04-22_v102.3_r3179.zip 2.53MB
sim-winsdl_2010-04-21_v102.3_r3175.zip 2.53MB

Can't find 3176 or 3177 :'(

The bug is fix in later releases too ?

EDIT : that's good there're fixed
I'm checking if the glitches I found are still present in r3190.

EDIT² : these are the three glitches I found.
The third happen only with the grey platform.

[Dwachs]

Thank you for investigating! Simply take the newest nightly to test for glitches.

As to your bugs:

Bug1: the signal is overdrawn by the pole of the tile behind. Hard to fix. Maybe move the signal some pixels to the front in the pak?

Imho, the other two glitches are pak-errors: the supermarket has this missing pixels. And this grey platform is missing some pixels in its foreground images to overdraw the foreground images of the stations behind.

[gauthier]

in the 1) it seems to be the catenary of the crossing which hide the signal.
in the 3) I think it's that the forward part of the platform is defined as back image.

EDIT : Useless to show a screenshot for the tree's placing problem 

[VS]

#3 - Yep, comes from pak. Actually at least 4 stations have this problem now.
#2 - I don't know how would I check that... investigating.



#3 (stations) is fixed now.

[gauthier]

There are two problems with trees.

1) as everyone know there are sometimes placed on a tile next to their one.
possible solution : on a tree source file we could define a "base pixel" which must be the base of the trunk.
Afterwards the code of tree's placing should be fixed, so trees will be placed only on their tile.

2) as you can see in attached picture : tree's shadows sometimes intersect so it's a complete blackout ...
Two solutions :
a heavy solution would be generate a 50% transparent shadow under the tree.
an easier one would be to make shadows all at the same place on the source files and in the code force the trees to place only on certain pixels so shadows can't intersect.

[VS]

Anyone wishing to take a shot at trees, it's probably void baum_t::calc_off() And I don't understand it, but that's okay, because I can try it á la Monte Carlo... And it seems its results are good. (Charts are anisotropic so look at axes)

Perhaps there is an hidden assumption about tree alignment that is violated by graphics? Such as that the tree "starts" in the center of tile? It feels that way. Most of pak128 trees aren't centered, but made to fit on tile, so...

I'll look if there isn't even a problem with tile size - the code gives randomization in fixed range, while it should perhaps vary that...

edit: Spot on with graphics requirements - everything old in 64 (ls_*.png) is centered.

[Dwachs]

Imho it looks like trees should be centered at a tile.

The offset-calculation looks right for flat tiles (case 0:). There should be a calculation of the offsets for all different slopes differently, these three different cases cannot cover all possible slopes right. After rotation the offset is wrong anyway (the tree magically changes its position in 3d space, here a z-offset is needed or some sophisticated rotation calculation). After rotation the sorting of trees on a tile has to be corrected too.

Long list of possible bugs (all what I remembered now).

[VS]

Rotations aside, perhaps the resulting areas are clipped so that they are always inside resulting visible tile? Also, it seems there is this TILE_STEPS thing so tile size does not matter. False alarm

Tree images should be easy to fix on pakset side with offsets (I hope!). The hard part is of course finding the offsets

edit: this is a very productive thread...

edit2: Perhaps recalculating position after every rotation would be enough? So that after rotation, placement is correct, but not a rotation of old placement. Yes, this is "lossy", but does it really matter much? When there is a bunch of trees on a tile, it does not matter to me much how are they arranged... If it is still absolutely critical to maintain the spatial pattern after full 360°, these randoms could be replaced by something deterministic inferred from coordinates. As a bonus, if you used rotation as part of that calculation, you could possibly make it work 100% if it was some table lookup (that's lossless again with some work to get the tables to match).

[gauthier]

I definitly can't understand anything what you're talking about XD

The solutions I purposed seem to be wrong ... why ?

[Dwachs]

We are talking about your problem number 1. It seems like the code already assumes a certain position of the tree graphic: namely the root of the tree should be in the center of the tile (in the png files). Then the wrong positioning of trees comes from the wrong positioning of the trees in the paks.

[VS]

#1 in first post was real. I just noticed... for some reason here the building worked well even without needs_ground.

Hmmm. Perhaps instead of restarting bug numbers for each post, they should keep increasing.

A quick recap so far:
* needs_ground - pakset, fixed
* tunnels - pakset, fixed; code?
* terraforming & bridge - ?
* signals - ?
* supermarket - probably pakset, todo
* platforms - pakset, fixed
* tree placement - pakset, todo
* tree shadows - ?

[prissi]

Since most of the remaining bugs are pak128 dependent, moved this topic there.

[Dwachs]

A quick recap so far:
* needs_ground - pakset, fixed
* tunnels - pakset, fixed; code  should be fixed - needs confirmation of bug reporter
* terraforming & bridge - code  should be fixed - needs confirmation of bug reporter
* signals - ?
* supermarket - probably pakset, todo
* platforms - pakset, fixed
* tree placement - pakset, todo
* tree shadows - ?

As to the signal bug:  maybe remove the overheadwire-pole? I mean, it is not clear whether the ne and sw poles should be drawn before or after vehicles. In fact, the ne-pole should be drawn after vehicles driving n-s but after vehicles driving e-w! Such glitches can be observed in the game. Conclusion: remove these poles.

Tree shadows: there is nothing that can be done in the program. Imho this is not so important ...

[VS]

You're right that the side poles are ambiguous, and that alone is reason to remove them and thus resolve this.

But the signal / pole clash has a different reason. Graphics, but these are again forced by other circumstances. Let me explain. The poles are on the crossing tile, 4 around the center. Nothing wrong there, I think. What is causing problems is the signal, which is moved forward from its "home tile". And that, I guess, is because of where trains stop - far in front of tile. So one could conclude the vehicle movement algorithm is behind this...

Tree shadows can die

Thanks for all the reports (gauthier) and fixes (Dwachs)!

[gauthier]

normally a thing on a tile should be drawn after things on the tile behind, write ?
The signal must be drawn after the electrification ...

[Dwachs]

normally a thing on a tile should be drawn after things on the tile behind, write ?
The signal must be drawn after the electrification ...

This is how its used to be. Now this is more complicated to fix the glitches with vehicles and stations:

The drawing sequence per tile is:
a) background images
b) background image of tiles in front (if ways are connected, only the part that goes into the tile behind is drawn)
c) vehicles on tile
d) vehicles on tile in front
e) front images
f) front images of tiles in front

[gauthier]

I see ...

This is a problematic trouble ... I will think about it some days, if I find a solution I say it

[gauthier]

happens with all stations.

[Dwachs]

what are we suppose to see? what is the bug here? the tree?

[gauthier]

another one (sorry for tiple post)

But I had an idea to make all tunnels'entries glitches disappear easily.
Why not add a special color which would be put around the tunnel entry (in the source pictures) at the place of the slope, and in game this color would be drawn other every thing (catenaries, signals, vehicles, ...) and replaced by the normal slope picture ?

I hope you understand my idea, if it's not clear I can draw some schemas

(yes the bug is the tree between the two platforms of the station)

EDIT : one more : the red station must be like the green one, this layout glitch seems to be caused by some underground constructions.

[Dwachs]

But I had an idea to make all tunnels'entries glitches disappear easily.
Why not add a special color which would be put around the tunnel entry (in the source pictures) at the place of the slope, and in game this color would be drawn other every thing (catenaries, signals, vehicles, ...) and replaced by the normal slope picture ?

I hope you understand my idea, if it's not clear I can draw some schemas

I understand, had the same idea some time ago. But no idea how to implement this.

(yes the bug is the tree between the two platforms of the station)

on which tile is the tree actually? behind the station / on the station tile / under the station ?


Edit: what station-pak is that on the screenshot? could you upload a savegame somewhere (with addons that do not belong to plain pak128)?

[gauthier]

It happens with every station, the tree is of course behind the station. But I realised that in fact it's the tree placement problem, so it's not a independant glitch

[Dwachs]

Edit: what station-pak is that on the screenshot? could you upload a savegame somewhere (with addons that do not belong to plain pak128)?

I meant the ituation on bug2012-endofworld.

[VS]

I don't even understand what is 2012 showing. Are the wires connected across wrong tiles?

[gauthier]

you see two stations, each one is pointed by an arrow. They're SNFOS stations, with 8 pictures. Normally the extremity of the station is the same as the one pointed by the green arrow. But there's a glitch pointed by the red arrow which occurs when something is built under the station. I often see this glitch.

[Dwachs]

@gauthier: please upload a savegame together with the needed snfos pak's. I could not reproduce this with a pak.german station.