in my previous games (using my custom based engine), im using an equally sized frame on my sprites, like for example each frame is 100x200 or something like that, so if i have 5 frames then i

have like a size of 500x200, but i can see sprite images sample online with different size of frames, how are other engines handle it?

secondly, how to handle offset differences in position of sprites?

like for example, i have a single IDLE sprite of one row, 500x200 (each frame is 100x200), and i have a separate sprite sheet for walk of with size 1000x200 (with each sprite 200x200), the talk sprite sheet frame is bigger than idle since it requires wide frame for the legs, etc.

how to handle the offset difference of the two? like if i play both sprite, they should be on the same position when IDLE->WALK or WALK->IDLE.

how are professional engines handle this differences in sprite size and frame positions?

It's normal to have a document -often XML - that has the frames mapped.

For example, using a python .py file:

#Format Sprite[(StartX,StartY),(EndX,EndY)]
Sprite[(0,0),(100,200)]     #100*200 sprite
Sprite[(100,0),(220,200)]   #120*200 sprite

You will also scale the polygon that the image is drawn on to allow for the new size each frame. It's also possible to keep maps for the bounding box.

You could make these maps by hand as you make each sprite or you could use a sprite packer to pack and map sprites. There are a few sprite packers on the web that will export a map for you.

Even if you use your own engine it's recommended you follow the power of two rule, it helps keep things like antialiasing and mipmapping simple.

It's only the sheet that has to be power of two, so pad your 500*200 sheet as a 512*256 one by adding blank pixels to the sheet.

As Scouting Ninja denoted, you need to have associated data for the sprite. Things I used in the past for each sprite in a data driven approach are:

* A unique ID.

* A references that denotes the sprite sheet to be used.

* A frame which denotes the pixel region on the sprite sheet.

* A base point, given relative to the frame on the sheet.

* A transition table with

** a condition,

** the ID of the following sprite,

** a distance that denotes how to alter the world / screen position when using this transition.

Regarding the base point: It defines the one point that is mapped to the world / screen position of the sprite. For example, each "legged figure on the ground" sprite has its base point between the feet on the ground. The base point need not fit into the sprite's frame; e.g. the base point may be on the ground during jumping.

Regarding the transition condition: Of course, player input (in case of PC) oder AI decisions (in case of NPC) plays a role here, and automatic transitions are possible. But also timing can be incorporated here, e.g. input need to occur in a defined time range. Even entity or world state flags can be used.

For advancing look at the transition table of the currently selected sprite, pick the first transitions that has its condition computed to be true, alter the world / screen position accordingly to the offset, and set the referenced follower as the new selected sprite.

For rendering fetch the base point of the currently selected sprite, multiply it with the "sprite-to-screen" pixel ratio, add the result to the current world / screen position. Fetch the size of the sprite's frame, scale it by the same pixel ratio, add it to the position computed beforehand, and use this for the vertices of the image carrying rectangle. For each vertex, set the belonging frame co-ordinates for the texture access.

The above is somehow course, of course; the details need to be elaborated with respect to the engine.