FS#6357 - positioning of train vehicle sprites

Attached to Project: OpenTTD
Opened by Michael Blunck (mb) - Friday, 07 August 2015, 09:13 GMT
Type Bug
Category Interface
Status New
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


Positioning of train vehicle sprites is all a mess in the diverse windows/lists.

Granted, since varAction2 var10 (display different sprites in GUI), this can be worked around, changing it from a bug into an inconvenience. However, why should a newGRF provide 4 identical sprites (only differing in y-position) to compensate for the different base y-coordinate in the diverse windows/lists?

E.g., to position a simple rail car with repect to the same y-position it needs 3 (or even 4, incl the purchase menu) identical sprites, only different in y:

// test all those different offsets in the various windows/lists
// Depot
sprite(db#vt95.pcx 226 8 01 11 28 -14 -7)
// Details/refit
sprite(db#vt95.pcx 226 8 01 11 28 -14 -9)
// Liste
sprite(db#vt95.pcx 226 8 01 11 28 -14 -8)

In addition, some windows show silly assumptions with regards to vehicle sprite placement. E.g. the train details window reserves 4 rows of empty pixels above the text (see pic), unnecessarily (in a rather low-ceilinged box), only to clip the sprite on its bottom when being shifted downwards. Etc, pp.
This task depends upon

Comment by andythenorth (andythenorth) - Wednesday, 16 September 2015, 18:54 GMT
I am +0.5 to this, having to chase down these different views is inconvenient yak-shaving.
Comment by andythenorth (andythenorth) - Thursday, 31 August 2017, 07:51 GMT
FS#6318 is related; I would rather see the need to use var 10 removed by fixing the issue at root cause, then FS#6318 closed as "won't fix".

However fixing the issue at root cause might be a nest of snakes w.r.t backwards compatibility.