Aseprite sets Doom sprite offsets to 0

[PopeRigby]

Doom has a XY offset for all its sprites. Aseprite seems to set this to 0, which causes the sprites to be off-center.

Video of it happening.

[KashouC]

As a work around I would recommend something like this to alter the sprite offsets:

https://forum.zdoom.org/viewtopic.php?f=39&t=56521

[PopeRigby]

That does take quite a bit of work if I'm just modifying and testing, though.

[dacap]

Hi @PopeRigby, you are looking for a pivot point for each frame right? I don't know how Doom handles this offset information, does Doom read the information from a specific data inside png files or in which format?

In case you can generate the offsets in some file, a possible workaround could be:

1. creating slices of 1x1 indicating a hotspot
2. creating a script to output the slices information

The only problem is that slices do not support animation too well yet, so you might need to use different slice names for each frame 😢

Anyway in a future we would like to add a pivot property (per frame).

[PopeRigby]

This Doomworld thread should give you a better idea of what's going on.

[dacap]

I wasn't able to see the video (it's still loading) but I would say that handling Doom file formats is not in the scope of Aseprite.

[PopeRigby]

It's not a Doom file format. It's a normal PNG with two extra parameters. I would say it's in the scope of Aseprite to not zero out these parameters.

[dacap]

Oh thanks, that's the kind of information I needed to know to understand the issue. Didn't know that Doom uses some internal png metadata to store the offsets, etc. In case you have some example .png I can test, that would be great to have for testing purposes. (You can send the files to support@aseprite.org)

[PopeRigby]

Alright. I'll also link it here, for transparency's sake.

[PopeRigby]

If I open up Slade (a Doom editor), you can see that the original sprite is centered and has an offset of -121 and -108

If I simply save that same sprite in Aseprite, and open it back up in Slade, the offset gets set to 0 and 0, and the sprite hops up to the top left corner.

[dacap]

This bug is related to http://www.libpng.org/pub/png/spec/1.2/PNG-Ordering.html specs, the recommendation for png editors is to keep all unknown safe-to-copy ancillary chunk in the edited png file. I'm working on this issue right now.

[dacap]

I've just exported the same image with a possible fix on Aseprite for this issue, could you @PopeRigby please check if this png:
works in Doom editor correctly?

If it does work, we'll try to release the fix in 1.2.16 soon.

[PopeRigby]

Yes. That works.

[dacap]

Thanks for testing, the fix will be available soon.

[PopeRigby]

Thanks!

[PopeRigby]

When will the update with this bugfix be out?

[dacap]

Hope this week (we want to include other fixes), in case that you want to give a try to a beta with this change, I can build a special version for you, contact me at support@aseprite.org from the email address that you've used for your purchase.