Sprite Aligner

[wallyweb]

I am using OpenTTD 1.5.0-beta1 and I am working on a bridge.
It has been well over a year since I last used the sprite aligner tool.
I noticed that the x-rel and y-rel values were rather high (see image), but the tools never lie, do they?

sprite_aligner.png (4.6 KiB) Viewed 4443 times

I spent a week trouble shooting my code, all to no avail.
After many screenshots and much trouble shooting, I figured it out. THE TOOL LIED!
Here is the code that goes with the image:

Code: Select all

9 C:\mps\_tools\grfcodec7\sprites\UrbanTransit0Btest.pcx 80 16 09 31 45 -21 -4 // 2438 86 09

The true x-rel / y-rel values are -21 -4
The sprite aligner inflates these values by 4.

I hope this information helps someone else who may find themselves in sprite aligner Hell.

[planetmaker]

I am using OpenTTD 1.5.0-beta1 and I am working on a bridge.
It has been well over a year since I last used the sprite aligner tool.
I noticed that the x-rel and y-rel values were rather high (see image), but the tools never lie, do they?

sprite_aligner.png

I spent a week trouble shooting my code, all to no avail.
After many screenshots and much trouble shooting, I figured it out. THE TOOL LIED!
Here is the code that goes with the image:

Code: Select all

9 C:\mps\_tools\grfcodec7\sprites\UrbanTransit0Btest.pcx 80 16 09 31 45 -21 -4 // 2438 86 09

The true x-rel / y-rel values are -21 -4
The sprite aligner inflates these values by 4.

I hope this information helps someone else who may find themselves in sprite aligner Hell.

OpenTTD does give the alignment values of the cropped sprites when you encode your newgrf using nml's or grfcodec's cropping feature (as they remove the extra blue pixels and how can one tell what was the original value. Decode your grf and compare with those values instead of those withing your original code).
Additionally it shows the values for the zoom level you are currently using - information which you conveniently cropped from your screenshot-snippet.

[wallyweb]

OpenTTD does give the alignment values of the cropped sprites when you encode your newgrf using nml's or grfcodec's cropping feature (as they remove the extra blue pixels and how can one tell what was the original value.

As you can see from this sprite

cropped_sprite.png (1.07 KiB) Viewed 4422 times

which is the exact one that the sprite aligner was pointed to, there are no excess blue pixels. There never were. I have no need of a cropping tool or feature mainly because I never leave anything to crop.

Decode your grf and compare with those values instead of those withing your original code).

Wouldn't it be much simpler if the aligner simply displayed the real value, the way it used to do?

Additionally it shows the values for the zoom level you are currently using - information which you conveniently cropped from your screenshot-snippet.

Considering that I did experiment before starting this topic and that I found the values remained the same for every zoom level, the conveniently cropped zoom level would have been redundant and perhaps even confusing.

I am sure that there must have been a good reason to make changes to the sprite aligner such that it now provides the fine tuning of one click per quarter pixel and displays values in quarter pixels. I simply do not know that reason. Perhaps someone could point me to the documentation.

[TadeuszD]

In my opinion displaying relative offsets for sprites would be the best way in many cases. It means that all not shifted sprites should have (0, 0) offsets in sprite aligner tool. If you obtain the best results with (-2, -1) offsets, you should simply add these values to your offsets, without caring about cropping.

Real sprite offsets are important only if you want to replace original sprite with its original positions.

Maybe the switch real/relative would be a good idea?

[Emperor Jake]

I am sure that there must have been a good reason to make changes to the sprite aligner such that it now provides the fine tuning of one click per quarter pixel and displays values in quarter pixels. I simply do not know that reason. Perhaps someone could point me to the documentation.

This bug has happened before. I remember experiencing it right after the closer zoom levels were first introduced.

[V453000 :)]

Aligning sprites is hell, I always do it this way:

1. open aligner

2. open all sprites I want to align, one by one - and write down the values for X Y offsets it says to an excel spreadsheet

3. I align stuff until happy

4. I write down the final values in the spreadsheet

5. I make a difference between them in the spreadsheet

6. I write down code values to the spreadsheet

7. I add the difference to code values -> I get values I should put into the code again.

Tedious, but works. What TadeuszD suggests would at least remove steps 1-5 which I would very much like.

With the "recent" change of making all of the values in x4 zoom, it became hard to align x1 as it is all times 4. Is it possible to add three buttons - x4, x2, x1 to the sprite aligner?

It made aligning x4 zoom possible, with x1 still being possible but tedious as you have to recalculate everything times 4 in your mind.

[3iff]

I've just spent hours trying to align a few sprites. I wish I had seen this earlier today...

Maybe I can finally get them lined up this evening.

[Emperor Jake]

I'll continue to use the simplest solution: to use 1.4.4 instead of a more current version for sprite alignment purposes