If you have two animation strips with different image widths, how do you manage to draw them for them to always seem at the same spot.

Say for example, on the one sprite the character is on the far right of the image and on the other animation sequence the character is in the middle of the image. So drawing from x - width/2 doesn't work in this case.

I was thinking of specifying an offset for each image, but it doesn't seem the right thing to do. What are your solutions to this ?

I don't clear about your problem. But on what I caught, seems you make it difficult on the sprites. why dont you just have same width sprites (if one need bigger place, the smaller sprite has empty pixels/transparant) and just play the offset or center points?

I have fiddled with this same problem before, Although its possible to do it in the programming side. Trust me when I say its far far far easier to just simply reposition sprites so that they are in the same size blocks. Like ReBirth said, just have the smaller sprites take a bigger image, just with more transparency around it.

IF the x-image.width/2 method isn't working, then your sprites are all probably out of alignment anyways, and just spend a little time repositioning them. Some programs I know can make this easier, I know photoshop and some sprite packers can assist in redistribution of splitting/rejoining images

I thought of that kind of solution, the problem is that say you have an image that is 30 pixels wide, and another is 64 pixels wide with the image of the character on the far right, that means your maximal width would be near 128 pixels(for the character to be centered), so you'll be using 4 times the required space for those 30 width sprites. It's seems a hell of a waste :/

I thought of that kind of solution, the problem is that say you have an image that is 30 pixels wide, and another is 64 pixels wide with the image of the character on the far right, that means your maximal width would be near 128 pixels(for the character to be centered), so you'll be using 4 times the required space for those 30 width sprites. It's seems a hell of a waste :/

if you have 2 images, 30 pixels wide, and 64 pixels wide. You would only need to make your 30 pixels wide image to be 64 pixels wide and center appropriately inside there. (thus youd go from 94 pixels(30+64) to 128 pixels(64+64), thats 36% increase, not a 4x increase? Also, depending on the type of image format/compression, empty/transparent spaces, do not 'usually' contribute nearly as much to the filesize, as one with scattered/random colored pixels, due to compression, even in a loseless format. So even a 2x image, with only added empty white space(transparent), does not translate to 2x filesize.

Could you upload an example of your photos? It would GREATLY help assist you in finding the optimal solution.

Also with a nearly 2x width. What exactly type of image is this? Perhaps it would be better served as multiple components linked together? i.e. a spider body is 1 image, and the legs are separate images instead of a super wide spider image.

Actually you're right, I could put the bottom one towards the right to gain place, so I'd be taking up 2* space width wise. The problem here is not a size issue on the disk. At worst it could take up some space when loaded as textures. I just find it weird, and not very dynamic. But the offset thing is weird too.

One way to handle the difference would be to create a class to hold the image and it's X and Y offsets. When you draw the image, use the images' offset values to correctly place it.For example:If you character is at 100x100. You top image would have an offset for X: -100 (or something). Thus when you call drawImage(), X will be the 100 of your character's location, minus 100 for the offset and you be drawn at 0x100.

My texture packer handles this. The artist creates the animation frames all the same size, with the content positioned so that it lines up across animation frames. Then the texture packer strips the frames of whitespace around the edges and packs them into larger image(s). It also outputs a text file with location of each frame in the larger image, the original image sizes, etc. Then in your game, there is a class (TextureAtlas in libgdx) that reads the text file, loads the large images, and can draw individual frames as if whitespace was not stripped.

Ok, so if I understand correctly, the solution you use is a mix of the two solutions I was wondering about. ie drawing sprites with the same width, but your program uses offsets that are stored and generated automatically.

I kind of like this idea of using offsets but making them automatically generated. I'll take a loot at your class.

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