+- The VG Resource (https://www.vg-resource.com)
+-- Forum: Discussion Boards (https://www.vg-resource.com/forum-133.html)
+--- Forum: Help me! (https://www.vg-resource.com/forum-137.html)
+--- Thread: 2D Sprites : Texture Atlas Inconsistancy? (/thread-30489.html)
2D Sprites : Texture Atlas Inconsistancy? - spritakas - 01-21-2017
Hello spriters!
I am new to using texture atlas method for sprite animation in my programs.
For example, I took "Sonic the Hedgehog" sprite from "Sonic Battle" hosted at Spriter Resource to use for a sample animation. Much to my surprise I inspected the file and found that each row does not have consistent pixels!
Using a GRID in Gimp I can see that if I treated four sub-boxes as a whole image, that some of the images would overlap!
Upon further exploring, I found nearly everysprite on Spriter resource is like this!
So clearly there is something I am not understanding- is there some universal tool or some common dimensions I am unaware of?
Or are all the rips I am finding just really bad quality?
RE: 2D Sprites : Texture Atlas Inconsistancy? - Guy - 01-21-2017
Your problem is you need to manually take the sprites and space them out into grids such as 32x64, 32x32, etc., i don't believe there is a program out there that will do this for you. You may have to spend a couple hours spacing out a handful of sprite sheets but its a simple task compared to actually ripping all those sprites.
As long as there is nothing wrong with the image clarity and the sprite animations are all together, then there's nothing wrong with the quality of the sheet.
RE: 2D Sprites : Texture Atlas Inconsistancy? - spritakas - 01-21-2017
Thanks for your reply!
I am blown away that there is no standard dimensions for rips!
Seems a bit out of the way to make content creators go through that when the ripper could just make a zip of each individual sprite separate?
When drawing my own sprites or anything 2D I keep dimensions constant to avoid issues like this.
Edit
Where would I go to find out the 'standardized' practice of doing what you say above to avoid errors?
RE: 2D Sprites : Texture Atlas Inconsistancy? - puggsoy - 01-22-2017
(01-21-2017, 12:52 PM)spritakas Wrote: Seems a bit out of the way to make content creators go through that when the ripper could just make a zip of each individual sprite separate?
The thing is that not all games can be ripped cleanly in a method that will just give out the frames as files. Many games, especially those on older consoles, need to be either hard-ripped (i.e. screenshotted with the background removed by hand or by disabling layers), or ripped using tile viewers. With both of these methods, the ripper has no knowledge of the bounding box or how to align them so that they animate well, at least not without tediously trying stuff out. Most rippers will align their sprites as best they can, and for viewing purposes that's sufficient.
Secondly, ZIPs aren't encouraged. While some sprites should be zipped up if they're really big, hard to organise or are just really miscellaneous and don't fit a sheet, most sprites should be sheeted. This is because the main point of the site is to archive and display the sprites for appreciation and reference. A ZIP requires a download and extraction, while a sheet can just be viewed directly on the site. This is especially useful when you're just browsing a game or looking for some references for a specific style.
When possible, people generally do organise their sprites in a way that makes them somewhat easier to animate or use in games (e.g. my Nuclear Throne sheets), but as I said this isn't always the case.
Due to the majority of sprites (anything outside of Custom) are from existing games, we focus more on displaying them than making them usable. People can of course use them in fan games and sprite comics, but ripping and organising sprites is already an effort and requiring people to make them easily usable just isn't justified. If you need to reorganise them into a usable format, well, at least you didn't have to rip them
We're more of a gallery than an assets resource (despite the name), so we focus on presentation more than usability.
RE: 2D Sprites : Texture Atlas Inconsistancy? - spritakas - 01-22-2017
Oddly enough, I found a different spriter's upload from the same game and found he made them usable (50x50)
I can understand from what you've described though! So it's more of a personal choice to take the time to make it more usable if the game packages the sprites in a not-so-friendly way.
Still, I would have liked having each separate sprite ripped into their own files (if that is the way the game originally packed them).
I'll just have to do some work myself
RE: 2D Sprites : Texture Atlas Inconsistancy? - spritakas - 01-23-2017
So after examining a sprite sheet that appeared to be sorted, I found that the the width and height actually calculated to:
48.444444444444444444444444444444
49.621621621621621621621621621622
per sprite...
This is a problem, as most practical uses in Texture Atlasing will need an integer, not a floating point/decimal.
How would I go about fixing the sheet properly? I have used gimp but am not familiar with settings snap-to positioning etc. I do not know where to begin to shift sprites by such a marginal amount.
For reference, I am using this sheet:
http://www.sonicgalaxy.net/img/sprites/gba/sb/shadow.png
Since the ones hosted on spriter's resource are not setup in this format
RE: 2D Sprites : Texture Atlas Inconsistancy? - puggsoy - 01-24-2017
The problem with the sheet is that although the sprites seem to be sorted well, he sheet's size is basically cropped to snugly fit the sprites, rather than their bounding boxes. Each edge touches at least one pixel. This means that the dimensions are a bit off and so you can't straight up calculate the size.
What I did was what you did, and then just kinda fiddled with the numbers, basically until they looked right. As you noted this stuff doesn't work with floats, and since we're talking about pixels it needs to be an integer (there's no such thing as half a pixel). What I did was use the grid in GIMP, which you can show with View -> Show Grid and configure with Image -> Configure Grid. (It can also be snapped to using View -> Snap to Grid.) I tried some numbers until it seemed about right and ended up with 50x50. I also had to put the width offset to -4 and the height offset to -8 (this is equivalent to adding 4 pixels to the left of the image and 8 pixels to the top). I'm not sure if this is the actual bounding box size but it seems good, none of the sprites are cut off and these can probably be used fine for animation purposes.
It appears that's wrong. I've kept it striked out for informative purposes, since that was my initial process, but after closer inspection it seems these sprites aren't actually equally spaced or aligned. For instance look at the sprites in second row, 5th and 6th column. They're identical except for the fire on his shoes. If you take one using the grid and overlay it onto the other one, aligning with the grid, you'll see that they don't match.
It might be the case that I just don't know the game very well and these frames are in fact supposed to differ in bounding box position, but it looks to me like they're not properly spaced. If that is the case then I'm afraid the only solution is aligning them yourself so that they animate well.
RE: 2D Sprites : Texture Atlas Inconsistancy? - spritakas - 01-24-2017
(01-24-2017, 03:45 AM)puggsoy Wrote: The problem with the sheet is that although the sprites seem to be sorted well, he sheet's size is basically cropped to snugly fit the sprites, rather than their bounding boxes. Each edge touches at least one pixel. This means that the dimensions are a bit off and so you can't straight up calculate the size.
What I did was what you did, and then just kinda fiddled with the numbers, basically until they looked right. As you noted this stuff doesn't work with floats, and since we're talking about pixels it needs to be an integer (there's no such thing as half a pixel). What I did was use the grid in GIMP, which you can show with View -> Show Grid and configure with Image -> Configure Grid. (It can also be snapped to using View -> Snap to Grid.) I tried some numbers until it seemed about right and ended up with 50x50. I also had to put the width offset to -4 and the height offset to -8 (this is equivalent to adding 4 pixels to the left of the image and 8 pixels to the top). I'm not sure if this is the actual bounding box size but it seems good, none of the sprites are cut off and these can probably be used fine for animation purposes.
It appears that's wrong. I've kept it striked out for informative purposes, since that was my initial process, but after closer inspection it seems these sprites aren't actually equally spaced or aligned. For instance look at the sprites in second row, 5th and 6th column. They're identical except for the fire on his shoes. If you take one using the grid and overlay it onto the other one, aligning with the grid, you'll see that they don't match.
It might be the case that I just don't know the game very well and these frames are in fact supposed to differ in bounding box position, but it looks to me like they're not properly spaced. If that is the case then I'm afraid the only solution is aligning them yourself so that they animate well.
Wow! Thank you for going through all that just to help me out. Bummer that its not already setup, would have saved me some time.
So to get started re-spacing the sprites, the method you outlined above to set snapping-to should do the trick?
RE: 2D Sprites : Texture Atlas Inconsistancy? - spritakas - 01-28-2017
Just wanted to follow up-
Talked to some animators who use these sprites in mini 2D-flash films:
Typically they convert each frame to a symbol and have Adobe Flash/Animator automatically proportion the sprites- and and x and y axis does have to be accommodated as a result.
I started unpacking them myself and wrote a subroutine in my C++ game that identifies the edging and corrects it.
A big thank you to everyone who helped! I wouldn't have gotten started into sprites without you!