TrueBrain wrote:

FYI: this bug is still valid. A solution seems rather tricky...

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1368

SmatZ wrote:

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 :)

Attachments

• sprite.diff (3.12 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1375

Rubidium wrote:

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.

Attachments

• Oosterwolde Transport, 22nd Aug 1999.png (16.12 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1376

SmatZ wrote:

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...

Attachments

• original.png (171.10 KiB)
• Retard Transport, 19th Jan 1995 #1.png (173.43 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1378

SmatZ wrote:

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)

Attachments

• sprite2.diff (3.65 KiB)
• Retard Transport, 19th Jan 1995 #8.png (173.34 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1382

SmatZ wrote:

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)

Attachments

• sprite4.diff (5.32 KiB)
• original1.png (180.32 KiB)
• original2.png (226.51 KiB)
• updated1.png (180.35 KiB)
• updated2.png (226.52 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1386

SmatZ wrote:

Hmm problem with shadows is even with planes... :-(

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1387

Rubidium wrote:

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 #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).

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1388

SmatZ wrote:

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

Algorithm:
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.

Attachments

• sprite6.diff (7.61 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1390

SmatZ wrote:

Ooops, clicked wrong button -
adding some screens and saves.

Attachments

• updated1b.png (180.36 KiB)
• updated2b.png (226.51 KiB)
• buildings.sav (9.25 KiB)
• buildings2.sav (11.38 KiB)
• hangar-old.png (12.97 KiB)
• hangar-new.png (14.08 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1391

SmatZ wrote:

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.

Attachments

• sprite6b.diff (6.44 KiB)
• problem.png (22.53 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1392

SmatZ wrote:

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 :-(

Attachments

• sprite7.diff (6.83 KiB)
• Retard Transport, 1st Feb 1995.png (189.50 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1393

SmatZ wrote:

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

Attachments

• sprite8.diff (7.57 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1394

SmatZ wrote:

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

Attachments

• sprite9b.diff (11.87 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1395

SmatZ wrote:

Change: catenary must be drawn after track fences

Attachments

• sprite9c.diff (12.59 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1398

SmatZ wrote:

My apologies, I removed one piece of code in the last quick edit...

Attachments

• sprite9d.diff (12.37 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1399

Rubidium wrote:

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)

Attachments

• more_issues.png (59.40 KiB)
• fs119.sav (83.11 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1400

SmatZ wrote:

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...

Attachments

• sprite10.diff (12.83 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1414

Rubidium wrote:

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?

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1421

SmatZ wrote:

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 :)

Attachments

• Retard Transport, 25th Jan 1995.png (169.10 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1435

skidd13 wrote:

The bridge over the tunnel isn't drawn right ATM. The tunnel is drawn over the bridge which isn't right IMO.

REV 10475

Attachments

• Roast Beef Moving, 3rd Aug 2092.png (61.95 KiB)
• Roast Beef Moving, 5th Aug 2092.png (61.78 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1545

frosch wrote:

I gave it a try myself:
http://www.tt-forums.net/viewtopic.php?f=33&t=33399

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment1758

skidd13 wrote:

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.

Attachments

• BUG.sav (107.24 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment2170

frosch wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment2173

Rubidium wrote:

'Just' a status update:

More clipping problems can be seen in #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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment3939

George wrote:

'Just' a status update:

More clipping problems can be seen in http://bugs.openttd.org/task/2078

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment4339

George wrote:

And one more problem I found. Visually BB overlap, but OTTD behaves as they are not.

Attachments

• bb-problem.png (8.01 KiB)
• ECSMachw.rar (341.10 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment4797

SmatZ wrote:

Another case in #2461

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment5131

frosch wrote:

more: #3029

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment6309

Rubidium wrote:

and for tunnels: #2970

This comment was imported from FlySpray: https://bugs.openttd.org/task/119#comment6326

Rubidium closed the ticket.

Reason for closing: Won't fix

See http://vcs.openttd.org/svn/browser/trunk/known-bugs.txt?rev=17554# L63

This comment was imported from FlySpray: https://bugs.openttd.org/task/119