SpriteAligner - Tool for aligning sprites directly in NFO

[AndersI]

I've made a small program - SpriteAligner - that reads an NFO file and gives you an easy way of aligning your train sprites. It is of course still Beta, and it is only tested on trains, so far.

Please try it out, and let me know what you think!

SpriteAligner version 1.0 (Windows.exe, but probably works under Wine)

Version
1.01 - Manage relative paths, crude 'tile limits' indicator
1.02 - Preserve eol comments, fix version number, spelling correction
1.03 - *Actually* (?) manage relative paths, fix cache error
1.04 - Yet another try on the relative paths
1.05 - Load PCX with odd byte counts, file name display
1.06 - Confirmation questions to minimize data loss
1.07 - Wallyweb's templates for SG, NG, RV
1.08 - Fixed loading of template image

[trainboy2004]

Works great

[DJ Nekkid]

i cant say more then ...


but can i make a feature request?

a "gray" box in the background of the sprite to show where it "should be", along perhaps with a small arrow

[planetmaker]

wow, cool
May I make a feature request similar to DJNekkid? It'd be cool, if the tile boundaries would be shown so that I get an idea how it relates to the actual tile.

[AndersI]

a "gray" box in the background of the sprite to show where it "should be", along perhaps with a small arrow

It'd be cool, if the tile boundaries would be shown so that I get an idea how it relates to the actual tile.

That's the tricky part. First of all, it depends on the shortening of the sprite, then it depends on what you are going to connect. A steamer + tender might have a very 'strange' alignment, looked at individually.

The program isn't smart at all, it doesn't know anything about the sprite, just that it is a part of an image file, so it's not very easy to 'know how it should be'.

All I know is that a 32px sprite should be centered

Anyone is welcome to draw a template, though, I'll be happy to include it as a background picture. Actual pixel scale, please, the program enlarges the view.

Maybe one should be able to load different template images? I'm not at all sure that what goes for trains is good for cars and trams?

[XeryusTC]

Hmm, imo these kind of prgrams are only useful if it knows about the boundingbox that the sprite is put in. I've seen quite some trains being aligned to the rails but not to it's bounding box making it look very odd when you attach wagons etc.

[DaleStan]

It doesn't seem to understand real-sprite lines of this format:

Code: Select all

   41 sprites/PlaneSetw.pcx 674 8 09 1 1 0 0
   42 sprites/PlaneSetw.pcx 690 8 09 1 1 0 0

I think it's a safe assumption that if you strip the first directory of relative paths, then you'll have a path relative to the NFO. Or maybe prepending "../" would be safer/better/easier.

[AndersI]

No, for the moment only full absolute paths work because of my Q&D IsRealSprite(...). And if/when I manage relative paths, I don't really understand why they shouldn't relate to the directory where the NFO is found? Is this some grfcodec quirk?

[frosch]

Is this some grfcodec quirk?

Grfcodec does not interpret relative paths relative to the nfo file, but relative to the directory where grfcodec is run from

[AndersI]

It doesn't seem to understand real-sprite lines of this format:

Code: Select all

   41 sprites/PlaneSetw.pcx 674 8 09 1 1 0 0
   42 sprites/PlaneSetw.pcx 690 8 09 1 1 0 0

I think it's a safe assumption that if you strip the first directory of relative paths, then you'll have a path relative to the NFO. Or maybe prepending "../" would be safer/better/easier.

Should be OK now (ver 1.01, see first post). I followed the first part of your suggestion. Please test/break it

[Ammler]

Tried your tool with wine, but wasn't able to see the sprites, how do I need to run it to see the sprites?
Maybe you could make a debug field (which is editable) to see the current location, where the sprites relative to will be.

Greets
Ammler

[DaleStan]

First the bug: When modifying the line

Code: Select all

   41 sprites/PlaneSetw.pcx 674 8 09 1 1 0 0 // something here

The comment is clobbered, rather than changing the xrel and yrel. If the comment is only "// something", the result is worse; the new xrel and yrel replace '//' and 'something'.
The workaround is obvious: "Don't do that, then."

Incorrect sprite numbers worked just fine.

Then, a couple warts:

• It freezes unpleasantly when loading large (in my case, ~1MB) PCX files, and it apparently reloads the file every time a new sprite is selected.
• The UI is not particularly discoverable. The button that looks to me like a calculator is particularly bad.
• The version number in the About window does not match the version number in the title bar.
• Again in the About window, the correct spelling of "alignment" has only one 'e'.

[AndersI]

First post updated with version 1.02.

The comment is clobbered, rather than changing the xrel and yrel

Fixed.

Incorrect sprite numbers worked just fine.

Is this good or bad? I don't actually understand what you mean.

It freezes unpleasantly when loading large (in my case, ~1MB) PCX files, and it apparently reloads the file every time a new sprite is selected.

It is expected to freeze once for each new file, it's caching the image files in memory. This works for me in my testing, where all sprites are in the same file (haven't had the time to test other combinations). I can click and hold down the down-arrow button and see all the trains whirl around on the screen, one after another (I even had to add a little sleep() to be able to see them good). Will try to find a faster PCX loader - the current one was ready and available with no additional work for me.

Feel free to PM me a NFO/PCX combo that reloads the file for each sprite, it's probably a bug in the cache handling...

The UI is not particularly discoverable. The button that looks to me like a calculator is particularly bad.

That's the (non-functional) auto-align button. I've hidden it for the time being.
Edit: At least I thought I had hidden it, but it's still visible - oh well...

The version number in the About window does not match the version number in the title bar.
Again in the About window, the correct spelling of "alignment" has only one 'e'.

Fixed.

Thanks!

[AndersI]

Tried your tool with wine, but wasn't able to see the sprites, how do I need to run it to see the sprites?
Maybe you could make a debug field (which is editable) to see the current location, where the sprites relative to will be.

It could be the same problem that DaleStan reported with relative path names in the NFO, please test with the new version (1.02). If that's not the case, I don't know, can you PM me a NFO/PCX the gives you problems?

Has anyone else managed to run it with Wine? I don't have a linux computer available, so I can only go on what other people tell me. My BlockCAD program is reported to work on wine, and this program is using graphics in exactly the same way, so I had my hopes up.

[DaleStan]

Incorrect sprite numbers worked just fine.

Is this good or bad? I don't actually understand what you mean.

Good. I fed it out-of-order and not-even-possibly-valid sprite numbers (specifically, I numbered several consecutive sprites 43, 44, 405, -46, 47) and it didn't choke.

It freezes unpleasantly when loading large (in my case, ~1MB) PCX files, and it apparently reloads the file every time a new sprite is selected.

It is expected to freeze once for each new file, it's caching the image files in memory.

Progress bars FTW. Not that they're easy to pull off.
Since it works for you and not for me, I'm guessing that the caching only breaks for relative paths. See attached for a test case; as far as I can tell, it doesn't matter which two sprites are selected; it will always reload the file when the second is selected.

Thanks!

No, thank you. It's so nice to work with programmers who fix bugs promptly and without objecting that I'm doing something stupid.

[Ammler]

Seems to work well with a fresh decoded grf, but doesn't work with sources like 01wagons.pnfo.

But then, you have very huge pcx files, which makes it very slow as it seems to reload everytime, as dalestan mentioned.
(Decoding with -h, seems not working, either.)

Greets
Ammler

[AndersI]

New version (1.03) in first post.

DaleStan: I've fixed the cache error. Stupid me was storing the relative name in the cache, but looking for the full name...

Ammler: I hope I've fixed that problem now, but I'm not sure. Where in the file tree is your .pnfo file stored (compared to the image files)?

Also, the .pnfo file extension, is that something 'universal' or is it only you? I could add that extension to the list, to save you some clicks. Any other often used extensions?

[Ammler]

New version (1.03) in first post.

fast!

Ammler: I hope I've fixed that problem now, but I'm not sure. Where in the file tree is your .pnfo file stored (compared to the image files)?

Also, the .pnfo file extension, is that something 'universal' or is it only you? I could add that extension to the list, to save you some clicks. Any other often used extensions?

Well, it is from the existing Makefile templates of Aegir or whoever, we have hnfo and pnfo, hnfor needs to be merged, pnfo go thought preprocessor or such alike. As you can chose All files, that isn't very important.

But I guess, the more important fact is that the nfo files can be on very different locations, maybe it would be helpful to have the possibilty to change your path? I.e. if you click on the link you see where it is, and you can also see, where the pcx is saved.

Something else, (not essential either) the pcx looks like you assume DOS? (pinky)

Greets
Ammler

[DaleStan]

My windows-paletted PCX files work just fine; I'd upload a test case.

[Bilbo]

Looks nice.

Is there planned support for aligning also other graphics? Like houses, signals, bridges... - you'll just need different "synchronization" background.