I like dumb code, so I actually don't deal with it. In stead, I do this:

a) I make all frames of an animation equal width and height, which probably means adding plenty of blank space in the slimmer frames. Different animations can have different dimensions thoughb) my positioning system does not orient from the top-left or bottom-left corner of a sprite/bob but from the center-bottom 'pixel'. This keeps the thing in the same place no matter that there are differences in animation width; even if you would allow different frame widths. Using the center-bottom also just makes things like floor collision checks slightly easier.

Unfortunately to properly work with a) does require a tiny bit of extra effort; I generate bounding boxes on a per-frame basis by examining the blank space and making the bounding box fit as tight around the opaque area of the frame as possible. But meh, thats the type of code you write once and copy everywhere.

I prefer your unchosen method, by measure them manually. With your sprite above, I just need store 7 (or 6) int in an array. Ofc you need to update code as art one but it could be avoided if you already fix at the sprite.

It means I need to manually find the integer coordinates (i.e. zoomed in using Photoshop)

It's better for arbitrary sprites than animations (where your names are going to end up char1, char2, char3, char4, etc).

In some cases using uneven sizes will result in a jumpy animation, if the character isn't lined up frame to frame. If this is the case, it would be much easier to just edit the sprites in Photoshop so that they are (a) lined up frame to frame, and (b) evenly spaced.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org