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!
pcxfind: A tool to automatically find sprites in pcx files
Moderator: Graphics Moderators
pcxfind: A tool to automatically find sprites in pcx files
- Attachments
-
- pcxfind-0.1.tar.bz2
- Version 0.1
- (3.72 KiB) Downloaded 67 times
Last edited by Maedhros on 25 Nov 2007 10:20, edited 1 time in total.
No-one's more important than the earthworm.
Re: pcxfind: A tool to automatically find sprites in pcx files
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.)Maedhros wrote: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
Now if you happen to be talking about some other part of NFO, please use the appropriate name.
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 wrote:so for instance it'll report grfcodec's sprite numbers as separate sprites.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: pcxfind: A tool to automatically find sprites in pcx files
Fine. Is that better?DaleStan wrote: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.
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.DaleStan wrote: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.
No-one's more important than the earthworm.
Re: pcxfind: A tool to automatically find sprites in pcx files
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.Maedhros wrote: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.
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.
Who is online
Users browsing this forum: No registered users and 33 guests