pcxfind: A tool to automatically find sprites in pcx files

[Maedhros]

I don't know about anyone else, but I find writing Action 1s and their associated real sprites one of the most tedious and sometimes daunting parts of grf coding. Finding all the x and y coordinates and the size of each sprite takes me quite a while, and it's quite easy to miss slightly and get those attractive white bars around the sprite.

So, finding myself with some time on my hands, I decided to write a program to do it for me. Point it at a pcx file and it'll give you a list of all the sprites in the file in nfo real sprite format. It's pretty stupid, and doesn't do any checking of what's in the sprite it's found, so for instance it'll report grfcodec's sprite numbers as separate sprites. The box-merging part isn't particularly clever either, so it may end up joining sprites that should be separate, or separating sprites into pieces. If you find anything like this, please let me know, and I'll attempt to fix it when a weekend comes around.

You shouldn't need anything to compile it except a compiler and a standard C library. It's released under the MIT licence, so you're pretty much free to do whatever you like with it except remove the copyright notices.

Have fun!

[DaleStan]

I don't know about anyone else, but I find writing Action 1s one of the most tedious and sometimes daunting parts of grf coding. Finding all the x and y coordinates and the size of each sprite takes me quite a while

Something's wrong with your definition of "action 1". Action 1s are pseudo sprites, always exactly 4 or 6 bytes long, and are stupidly easy to write. (The word "action" always requires that you be talking about a pseudo-sprite, and only actions 0 and 2 ever contain X and Y coodinates. Even when they do, they're not coordinates you could derive from the pcx.)

Now if you happen to be talking about some other part of NFO, please use the appropriate name.

so for instance it'll report grfcodec's sprite numbers as separate sprites.

They all have a well-defined shape and size; it shouldn't be hard to eliminate any "sprite" that matches those ten from the output.

[Maedhros]

Something's wrong with your definition of "action 1". Action 1s are pseudo sprites, always exactly 4 or 6 bytes long, and are stupidly easy to write. (The word "action" always requires that you be talking about a pseudo-sprite, and only actions 0 and 2 ever contain X and Y coodinates. Even when they do, they're not coordinates you could derive from the pcx.)

Now if you happen to be talking about some other part of NFO, please use the appropriate name.

Fine. Is that better?

They all have a well-defined shape and size; it shouldn't be hard to eliminate any "sprite" that matches those ten from the output.

True, but that would require actually looking at the sprite. I may or may not get round to it at some point; it's not terribly important to me at the moment.

[AndersI]

I don't know about anyone else, but I find writing Action 1s and their associated real sprites one of the most tedious and sometimes daunting parts of grf coding.

This part of the coding is quite easy to do with GrfMaker. You can always save the result as plain NFO and continue from there using other methods.

Admittedly, GrfMaker puts some (small) restrictions on the sprite placement in the pcx file, and isn't very happy with sprite numbers, but apart from that I don't see any obvious problem.

Caveat: I have only tried coding trains and buses with GrfMaker (yet), I don't know at all how good it is with other kinds of graphics.