Question about 2d sidescroller design

[BruceJohnJennerLawso]

Im currently thinking about creating a simple sidescroller game in C++, have gathered a few useful assets, but Im unsure about a particular design decision with regards to handling game objects.

When I create a character in game, they will need a sprite sheet covering all of the animations they can go through. Once this is loaded into memory, the image can then be assigned pose by pose to individual sprites which can be drawn individually case-by case. (ie the main loop just calls a draw function, which gets the right sf::Sprite based on the current animation state & draws it

The thing I'm not sure about is how best to handle the positioning of the sprites origin, ie should it be located at wherever the characters center of mass is at each image, or should it be at the very bottom of the sprite (at the characters feet)

The gist of my question is whether its easiest in this case to model a character as a physical object with their position denoted at their center of mass, or simply at the characters feet.

[Gobbles]

Really it's all a personal preference. For a simple platformer the origin isn't going to matter much, if at all. As long as it's consistent and your collision code takes into consideration where it's at, you could even keep it in the told left corner for all it matters.

My recommendation though is to not worry about the animations so much and get the platforming physics down first. This will give you a better idea of how the game will feel. Once that's in, setting up the animations will be a whole lot easier.

[Nexus]

In general, I think using the center as origin is a good idea, as it simplifies various things (especially when you start rotating and scaling). But it really depends on the operations you need. And I would separate logics (physical properties, velocity, ...) from graphics (sprite). There are several threads about this question, you could search a bit.

For animations, you might want to have a look at Thor.Animation which I have written, it simplifies animations (especially subrect/frame-based ones) a lot.

[BruceJohnJennerLawso]

In general, I think using the center as origin is a good idea, as it simplifies various things (especially when you start rotating and scaling). But it really depends on the operations you need. And I would separate logics (physical properties, velocity, ...) from graphics (sprite). There are several threads about this question, you could search a bit.

For animations, you might want to have a look at Thor.Animation which I have written, it simplifies animations (especially subrect/frame-based ones) a lot.

Sounds like a good idea to me. Thanks for the advice.
On the topic of animations, Im wondering how Thor (and presumably most similar libraries) handle animations exactly. Is it a sort of case where the draw sprite is sorted based on animation position, or does it deal directly with transforming parts of an image in a sprite?

[Nexus]

Thor's animations are very generic: they are just functions that modify an object (e.g. a sprite) over time. thor::FrameAnimation changes the texture rect of a sprite over time, so that different animation frames are displayed.

I'm not sure whether that answers your question, but you might have a look at the tutorial and API doc, which explains how animations technically work and how to use them.