FS#119 - Clipping problems

Attached to Project: OpenTTD
Opened by Michael Lutz (michi_cc) - Thursday, 13 April 2006, 23:02 GMT
Last edited by Remko Bijker (Rubidium) - Wednesday, 16 September 2009, 17:45 GMT
Type Bug
Category Vehicles
Status Closed
Assigned To No-one
Operating System All
Severity Very Low
Priority Low
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This is basically a repost of

This bug is still in current trunk code.

Vehicles may be overdrawn by ground sprites when build-on-slope is used. Planes are most often affected, which is expected as they are rather big compared to trains or trucks.

Old comment from Darkvater:

This bug is way more general then just airports. It happens with all vehicles that go on tiles built with the build-on-slopes feature. This can especially be seen with larger vehicles (thus the airports-bug), but also thalys, ice-trains, can be seen having this bug.

Maybe having correct slopes will fix this bug, but I'm not really sure because if you look closely they also have this clipping problem (just not on airports because it is not allowed to build airports on such tiles).

See the attached screenshots for example.
This task depends upon

Closed by  Remko Bijker (Rubidium)
Wednesday, 16 September 2009, 17:45 GMT
Reason for closing:  Won't fix
Additional comments about closing:  See /known-bugs.txt?rev=17554#L63
Comment by Patric Stout (TrueBrain) - Thursday, 14 June 2007, 18:03 GMT
FYI: this bug is still valid. A solution seems rather tricky...
Comment by Zdeněk Sojka (SmatZ) - Thursday, 14 June 2007, 22:46 GMT
Probably found a solution.

The problem:
When calculating ParentSprite precedence in ViewportSortParentSprites(), the size of ChildSprites is not taken into account.

The attached diff is not in any final state - you can just check if it works. Problem - not nice code, debugging output, crashing with
openttd: /mnt/svn/openttd/trunk/src/spritecache.cpp:470: const void* GetRawSprite(SpriteID, bool): Assertion `sprite < _spritecache_items' failed.

Just to make you know about I am working at it... The final solution is near probably :)
Comment by Remko Bijker (Rubidium) - Thursday, 14 June 2007, 22:56 GMT
Would be really nice if this is finally solved. Have tried to fix it myself too and failed (on several occasions), so I really hope you succeed.

However, my try failed due to some cases that I discovered in your preliminary patch. I show you these cases because even though it isn't finished yet, they are important testcases that are missing from the savegame. They are very easy to reproduce as you can see in the attached screenshot.

Comment by Zdeněk Sojka (SmatZ) - Friday, 15 June 2007, 10:44 GMT
You are right, the solution is not as easy. I was rather excited the train and plane got rendered well... but didn't think about these problems. Now I see it was rather luck it worked - even when sprites are not sorted at all, the situation si rendered better.

I did some other changes--

There is problem with the second depot.

Generally, it is hard to find any general order of sprites in a simple way - to assign some integer and then sort. There may be situations like 1>2>3>1, that cannot be rendered...
Comment by Zdeněk Sojka (SmatZ) - Saturday, 16 June 2007, 01:05 GMT
So... new updated version that seems to work...
Problem is that it is very slow, O(n^3), where n is the number of ParentSprites. Also, there are many fetches of sprites... It is not any final version, just a demonstration. Compare with original.png in previous post (the trees are ok, some of the just grew up in three days)
Comment by Zdeněk Sojka (SmatZ) - Sunday, 17 June 2007, 02:01 GMT
Another update, this seems to work almost flawlessly.
Compare original1/2.png with updated1/2.png (even in the second picture was incorrectly rendered border of the airport above the plane)
(I did tests with more situations, not only these two)

Rendering of trees is now not done via sprite combining as it caused some problems. Rendering is also a bit slower ( by 1/7 in my testcase ).
Problems - sprites with zero height (I found only 'O' and 'H' helipads in airports) caused problems, so they are forced to have height at least 1. Consequence is incorrectly rendered heli's shadow while above helipad (maybe problem of shadow code? - shadow can be placed one 'z' higher)

However, I do not want to make one big patch including changes in the code for heli's shadow, so I would consider this as a final version - if you do not find any bugs.
(there are maybe too many comments)
Comment by Zdeněk Sojka (SmatZ) - Sunday, 17 June 2007, 02:14 GMT
Hmm problem with shadows is even with planes... :-(
Comment by Remko Bijker (Rubidium) - Sunday, 17 June 2007, 07:24 GMT
I'd suggest to fix the helipad sprites in the grfs, i.e. just merge the concrete and helipad sprite together and use that as ground sprite. I think you should just comment out the lines of code that "drawn" those height 0 helipads in table/station_land.h and see whether there are any other problems.

Secondly the "concorde" in the savegame of  FS#119  has so blitting errors when it's landed (looks like the shadow is drawn over the aircraft, but that could be your "problem" with shadows).
Comment by Zdeněk Sojka (SmatZ) - Sunday, 17 June 2007, 21:59 GMT

Rubidium, you are right, shadows were absolutely wrong.

I did many tries and code changes, now it should be working. It is not as late as it was yesterday, so I had time to do more tests...
Now, even helipads and shadows are rendered ok (but there remain problem with its' height).

Correceted are almost all problems. Planes and trains at slopes, ... Even planes leaving hangar are rendered much better. (hangar-old.png, hangar-new.png)
The only problem remains - the RV and trains while on steep slopes. There would need to be probably total remake of slopes...

Main problem is that Vehicles' coordinates "xmin, xmax,..." are not correct. So, comparisons must be made at sprite (on-screen) level overlaying, not 'game coordinates' overlaying.

Changes for trees:
Trees are not combined sprites, trees' height increased

Searches for any sprite that can be rendered at moment. There are some conditions, commented in source.
If that tile cannot be found, a loop occured. Then is the old algorithm of comparing centers of the mass used.
Comment by Zdeněk Sojka (SmatZ) - Sunday, 17 June 2007, 22:02 GMT
Ooops, clicked wrong button -
adding some screens and saves.
Comment by Zdeněk Sojka (SmatZ) - Sunday, 17 June 2007, 22:10 GMT
Updated diff, without unneeded changes. Sorry I pressed wrong button and posted comment with diff...

I did many tests and it looks good. Though it is not perfect (see attachment), it is generally better than old attitude. So I hope :)

It can have problems when there are many overlaying sprites, but maximum effort was made to solve these situations in the best way. I suppose it is solved in a better way than it used to be.
Comment by Zdeněk Sojka (SmatZ) - Monday, 18 June 2007, 00:28 GMT
I found one problem - it really dislikes electrified railways, there is one example...

I added faster detector of loops. It should be used instead of sprite6.diff

Where the problem lies: when a loop is found in one of the first sprites, one sprite of them must be rendered. No matter if there is some others sprite outsidee the loop that is not blocked... Maybe the algorithm is not very good.

I though I will solve this problem, but I do not have much time anymore :-(
Comment by Zdeněk Sojka (SmatZ) - Monday, 18 June 2007, 14:33 GMT
Problems with el. rail corrected, was a stupid bug.
Increased height of rail tunnels, they were lower than catenary. (trams have tunnels of height 16, rail tunnels had 8)

I did some more tests and it is working with no problems... let me know if you find any, but I hope this is the last version
Comment by Zdeněk Sojka (SmatZ) - Monday, 18 June 2007, 19:47 GMT
Change: rail fences are now drawn as GroundSprites - it looks a bit worse at hills with foundation (if you don't know it looked different with old version, you would not notice)

I hope you are not offended by so many releases ... hope this work is useful
Comment by Zdeněk Sojka (SmatZ) - Monday, 18 June 2007, 22:38 GMT
Change: catenary must be drawn after track fences
Comment by Zdeněk Sojka (SmatZ) - Monday, 18 June 2007, 22:42 GMT
My apologies, I removed one piece of code in the last quick edit...
Comment by Remko Bijker (Rubidium) - Tuesday, 19 June 2007, 07:20 GMT
I've found some more issues with the sprite sorted:
- trains can be seen through the bridge.
- adding one way road "signs" 'remove' the tram track bits sprite. (Found out it was a problem in trunk too; now it's solved in trunk)
Comment by Zdeněk Sojka (SmatZ) - Friday, 22 June 2007, 13:26 GMT
Updated - should be better now.
The problem with one-way road is solved in the trunk.

Also included patch not to draw catenary over bridges, when el. railways are off.

Problems - vehicles going up/down slopes, track fence when next to tunnel or something (even the title screen has this problem)

I didn't test this one so throughly...
Comment by Remko Bijker (Rubidium) - Friday, 22 June 2007, 21:51 GMT
This starts looking really promising! Good job so far.

I could only reproduce the issue with the track fence next to tunnel (part of the fence misses when the tile north (east or west) is a tunnel entrance, right? Furthermore there are catenary glitches with the southern entrance of tunnels.

The issue with vehicles going up/down slopes I couldn't reproduce, maybe you're using some newgrfs?
Comment by Zdeněk Sojka (SmatZ) - Saturday, 23 June 2007, 22:08 GMT
Thanks! I am happy you find it useful :)

The problem with fences next to tunnel is because fences are drawn as ground sprites - probably I will revert this decision. But without that, fences are 'behind' foundated slopes, so they are barely visible.

Problems with vehicles is when it goes up/down a foundated slope. I am sorry for my English - images will be better :)
One image it there -> problem.png above in this topic
Second image attached - the foundation that is drawn over the bus is above it/next to it by game's coordinates, so it is drawn 'correctly'. That is because vehicles' sizes (x,y,z) are not set correctly. There would need some hacks to be done (like setting some flag 'this sprite is a vehicle/foundation/building...')
The problems with incorrectly set size (most noticeably heights) are everywhere :-(

The worst problem - the sorting algorithm is very slow. Polynomial complexity with O(n^4), but usually n^2 or n^3, depending how complex loops in sprites' overlaying are. It is roughly 3 times slower than the old one, now takes ~ 10%... (if there would be a multithreaded branch, rendering of the previous tick could be done in time of computations of the next tick - but it would take a lot of resources, doubling almost everything in the memory, causing slowdowns on single-threaded computers)

I am sorry, I do not have any time nowadays, next month should be better :)
Comment by Benedikt Brüggemeier (skidd13) - Sunday, 08 July 2007, 12:49 GMT
The bridge over the tunnel isn't drawn right ATM. The tunnel is drawn over the bridge which isn't right IMO.

REV 10475
Comment by frosch (frosch) - Tuesday, 31 July 2007, 15:01 GMT Comment by Benedikt Brüggemeier (skidd13) - Thursday, 20 September 2007, 14:26 GMT
r11132: Check marked tile in the savegame. If a train passes the house the wagons will be drawn over the house. It looks quite strange.
(application/octet-stream)    BUG.sav (107.2 KiB)
Comment by frosch (frosch) - Thursday, 20 September 2007, 18:42 GMT
Skidd13: That was my fault in r11102, but who expects the usage of 4 bit variables?
I will shortly open a new task with the fix.
Comment by Remko Bijker (Rubidium) - Friday, 18 April 2008, 20:09 GMT
'Just' a status update:

More clipping problems can be seen in  FS#1935 . These are currently unsolvable, but maybe someone gets a genious idea how to solve them.

In the fs119.sav there are still clipping problems near depots and the catenary of trams.
Comment by George (George) - Wednesday, 18 June 2008, 20:53 GMT
'Just' a status update:

More clipping problems can be seen in
Comment by George (George) - Monday, 29 September 2008, 18:35 GMT
And one more problem I found. Visually BB overlap, but OTTD behaves as they are not.
Comment by Zdeněk Sojka (SmatZ) - Sunday, 21 December 2008, 13:10 GMT
Another case in  FS#2461 
Comment by frosch (frosch) - Saturday, 11 July 2009, 09:04 GMT
more:  FS#3029 
Comment by Remko Bijker (Rubidium) - Monday, 13 July 2009, 22:08 GMT
and for tunnels:  FS#2970