This question is with regards to a 2D fighting game.

Horizontal flip, in logic, works fine for character sprites which need to face the other directiron, i.e.:

if(Player_facing==1)
draw_sprite();
else
draw_sprite_h_flip();

However, a problem arises if the characters are not centered in the graphic. For example:

Horizontally flipping it results in this

Now the main problem is, the drawing functions use the top left part of the image to be the "start" point. So when the player changes facing/direction, he actually "moves" a lot in the horizontal plane.

For a fighting game which relies on the actual sprite graphics to determine hit boxes and collision, this is of course unacceptable.

I've tried searching for some guidance on this, but I do not exactly know what this issue is called and hence turn up with mostly unrelated results. I tried manually plowing through the old posts with not much success.

As far as I can see, I would need to offset the placement of the sprites. However, my sprites are extremely varied in shape and size, and I cringe at the thought of having to manually determine, then test where the "center" point of each frame is.

Another way which I have thought of, is to tell my artists to manually determine an anchor/reference point at the feet of the character, and to extend the size of the bitmap to as much width/height as is needed to keep it right at the center (down to one pixel accuracy). This seems logically correct, but would result in, I imagine, a lot of extra effort on the part of my artists which should not be theirs (hey, artists should just draw draw draw!). Secondly, it would increase the overall size of my graphic resources and indirectly, program memory.

Thus I pose this question to the community: how would you overcome this issue?

If I am missing something blatantly obvious, please point it out to me as I am new to game design and implementation in general.

Thanks for any input

P.S: That is not my sprite, I merely use it as an example.

EDIT: wow the pictures aligned weird, but they looked fine in the preview, fixed

PPS: Why did the draw_sprite_h_flip lose its underscores?

The only ways that I can think of are:
Increase the canvas size of your sprites and make the start_x actually in the centre (where the collision mostly occur), or store the collision circles/boxes in another file or in your code... I know that you mentioned both of those, but I can't think of any other ways at the moment.

Alas, you answered your own question.

Sometimes the obvious answer is the best one. Any other method you can come up with to solve this problem will take some amount of extra effort. When it comes down to it, adding in all those points is not as dramatic as it seems. The only tricky part is making sure each frame has the correct alignment point assigned to it. One way to do this is to encode the offset from the top left corner into the top left pixel. When the frame is loaded you read those offset coordinates from the pixel's bits and then set that pixel to transparent. Use two pixels even if you need more bits than one pixel can provide based on the bit-depth of the sprites.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Thanks for the info.

I believe I can establish a standard with my artists with regards to determining the center point, and have them pass back to me the coordinates of pixel determining said center point.

That's a very interesting idea, I did not know you could encode data into pixels

As I was reading that, I was thinking of an alternative way of doing it (as I have no idea how to do what you said), namely using extra attributes (x, y) linked to each frame in the datafile. Then use get_datafile_property and use it to offset the blitting.

I'll talk to my artists and see what we can come up with, thanks again!

On a different note, I'd consider doing the mirroring of sprites at load time rather than every time (or even cache on demand), you'd be surprised how much graphics data you can fit nowadays

That's what I use, and the datafile has way over 400 sprites. I modified the Allegro grabber to display this spot as a flickering pixel, and allow to move it manually with cursor keys (It's a change I keep re-implementing with each Allegro upgrade, since 3.9 !) The properties are then stored as XHOT and YHOT properties.
After loading the datafile in the game, I read these properties into an array for faster access.

POTEMKIN BUSTER

Anyway, here's another vote for adding a sprite offset to each frame. It also solves the problem of frames being of different sizes.

Different sized sprites are unavoidable, I have x_offset and y_offset in my frames class.

Well you could extend the left side of the graphic out a bit with magic pink so the graphic is actually centered in the image But that might cause some other problems later on.