Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

positioning of train vehicle sprites #6357

Closed
DorpsGek opened this issue Aug 7, 2015 · 4 comments
Closed

positioning of train vehicle sprites #6357

DorpsGek opened this issue Aug 7, 2015 · 4 comments

Comments

@DorpsGek
Copy link

@DorpsGek DorpsGek commented Aug 7, 2015

mb opened the ticket and wrote:

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:

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

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.

Attachments

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/6357
@DorpsGek

This comment has been minimized.

Copy link
Author

@DorpsGek DorpsGek commented Sep 16, 2015

andythenorth wrote:

I am +0.5 to this, having to chase down these different views is inconvenient yak-shaving.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6357#comment14057
@DorpsGek

This comment has been minimized.

Copy link
Author

@DorpsGek DorpsGek commented Aug 31, 2017

andythenorth wrote:

#6318 is related; I would rather see the need to use var 10 removed by fixing the issue at root cause, then #6318 closed as "won't fix".

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


This comment was imported from FlySpray: https://bugs.openttd.org/task/6357#comment14664
@TrueBrain

This comment has been minimized.

Copy link
Member

@TrueBrain TrueBrain commented Apr 13, 2018

I was about to ask .. doesn't fixing this cause all current NewGRFs to break? But if it is about removing something, backwards compatibility is easier.

This ticket will be far from easy, but it sounds really silly, so solving it should be on some list.

@andythenorth

This comment has been minimized.

Copy link
Contributor

@andythenorth andythenorth commented Jan 7, 2019

Although this would be nice to have, it isn't something we expect to fulfill in the next year, and on that basis I'm closing it. We do this to keep the project manageable, productive and fun. We hope you do understand. Thanks for contributing though! Here you can find more about how we handle feature requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.