New Sprites - Help me understand PNG offsets

[Janitor]

I am creating sprites with 3D software. My graphics render with a large amount of negative space.

Too much negative space.

 

When I import my sprites into my Pk3 with SLADE, my large original images are positioned perfectly when I use the 'auto offset' feature. They appear exactly as I intend them to. But these files are huge.

 

I have used ImageMagick to trim the negative space and reduce the file size. The resulting trim of the above image looks like this:

Way better use of space. This is a good crop.

 

After I import my cropped images into my Pk3, auto-offsetting them results in incorrect positioning on the screen.

 

Left - Incorrect Positioning with cropped image. Right - Correct Positioning with large image.

I have a large volume of sprites which are impossible to manually realign by hand. Some of my monster sprites have thousands of frames. It is my understanding that offset data is stored in the PNG somehow. This is where my knowledge falters... I have only a very basic understanding of how data is stored in files, and don't really have a grasp on manipulating binary data. My ideal solution is one where I have to do as little work as possible. I would like to know if anyone has any experience with ImageMagick, and knows if there is a way to amend my command to simply inject offset data.

let cmd = `magick ${file.name} -fuzz 1% -trim  trimmed_${file.name}`

If this understanding is incorrect, is there some existing and tested solution I could implement or an alternate way to approach this?

[ketmar]

do not crop empty space at the left side. because i don't think that there is a ready-to-use utility to mass-manipulate offsets.

[Gez]

Sprite offsets are a non-standard part of the PNG format (which does contain something for offsets, but print offsets, a totally different thing). As a result, do not expect non-Doom-specific utilities like ImageMagic to handle sprite offsets.

 

Note that PNG is a compressed format. Having a large area of identical pixels (in this case, transparent ones) is not necessarily a problem. I'd recommend using something like pngOUT or pngCrush or OptiPNG or similar to get them as small as possible. You can then make another pass with DeflOpt to shave off a few more bytes if you want. (Run DeflOpt after the other program. The first thing is to brute-force the best compression scheme, and then DeflOpt makes the decompression table smaller.)

 

SLADE has a built-in feature to run these tools on a batch of PNGs. Be warned, though, it can take a long while to run, especially if as you said you have "a large volume of sprites"; so just leave it running and go do your grocery shopping or something.