Unless this is some new new license change at pixabay, I've already taken a look at this. A similar concern was raised on the forum thread here a few months back. I think it's a pretty dirty move and I certainly won't be using pixabay moving forward, but the good news is they don't get to sneak into your project and change the license on assets already in use.
More directly addressing pixabay's change specifially, see the discussion on submissions derived from pixabay assets (before their license change) here and here.
TL;DR: Before 1-1-2019, pixabay used the CC0 license. pixabay's new stipulations do not apply to any OGA submission prior 2019. Any assets obtained from pixabay before their license change retain their CC0 status. CC0 cannot be revoked, so pixabay changing their license on CC0 assets is irrelevant. However, you should not download assets from pixabay today and treat them as if they are CC0, since they may not be the same assets as those that were available under the original CC0. Make sure the Published date on the pixabay page is before 1-1-2019.
hehehe! I think if OP is having trouble with tools like piskel for merging 2 sprites, coding something in magic-script may be a bit like using a steamroller to kill a spider. Still, imagemagic is a great tool.
It appears to me the animation is running slower than the movement speed. Try moving the character fewer pixels per move or cycle through more animation frames per move. I understand this may be difficult since you have a set number of animation frames as well as a set distance between tiles. Try working in multiples of your animation frames: if you have 6 frames in a walk cycle, try bumping your animation rate so it renders 12 frames per move (or 2 full walk cycles), if that still looks "slide-y" bump it up again to 3 walk cycles.
You may have to decouple your walking animation speed from movement distance. Make it so as long as the character is moving, the walk animation is running. Then, if the character stops, stop the animation as well and set the characcter back to the standing-still frame. That will allow you to set the animation speed independent of the distance traveled. Once the character stops at their destination, it may jump from a middle-of-a-step frame of animation to a standing-still frame, but it usually doesn't look as unnatural as you'd expect.
If that isn't making sense to you, let me know. Can you make the character spritesheet available here for me to use in demonstrations?
Yes, that method should work for other dimensions just as well. Simply change the values you're entering on step 7. :)
As for how to determine the frame size and offset... Rubberduck explicitly listed 16x16 in the tags for this one, but it's not always so easy.
Usually I'll pick a tile in the spritesheet with a clear border (for example, the trusses at 160,80)
Open the spritesheet in GIMP.
Menu bar > View > Show grid
Menu bar > Image > Configure Grid
Then I start adjusting the grid width and height until the grid lines seem to line up with the tiles, paying special attention to the tile I picked out earlier.
It involves some guesswork, but this method works pretty fast for me. Most spritesheets have dimensions in powers of 2, so 16x16, 32x32, 64x64 are pretty common. Often the width and height are mixed and matched, though: 16x32, 32x48. On the other hand, there's no rule that says sprites MUST be powers of two, so you'll sometimes encouter sprites with strange dimensions like 21x33. Other times, the graphics is set to conserve as much room as possible, so the sprites are not arranged in a grid (sprite-atlas) but in wherever they will fit.
For example, this pixel dungeon spritesheet (below) has sprites in multiple sizes (16x16, 14x20, 32x32, 35x35, etc) In these cases, no amount of grid tweaking will properly slice all the sprites. Some tools like Unity have texture atlas tools that help auto-slicing the atlas, but other than that, there isn't a good easy way to do it with atlases. Just open it in gimp and start manually cutting each sprite out.
Ah, looks like rubberduck set them up so the overflowing tiles are adjacent. I was wrong about the offsets. It's a 16x16 spritesheet with some tiles having overflow. So, here's how to split them out into individual tiles:
The sprite dimensions for this sheet are not grid-aligned. They appear to be 16x16, but separate sections have different offsets, which makes this more of a "sprite-atlas" rather than a spritesheet. Can you tell me where this came from?
As mentioned in that other tread, I usually use GIMP, though Piskel also does well. It would help us understand what you're trying to accomplish if you would attach the spritesheet you're working with to this topic thread.
@MetroVG Studio Bluebird: This submission has been marked as having a licensing issue while we investigate. Downloads are disabled. Can you provide more information about the circumstances? Please Private Message me links to the documents you've mentioned and/or the relevant JASRAC entries.
Don't be calling it before the finish line; there's 29 people participating and they still have 10 days to submit. I turned in my last jam submission with only 8 minutes left on the timer. :)
???
Unless this is some new new license change at pixabay, I've already taken a look at this. A similar concern was raised on the forum thread here a few months back. I think it's a pretty dirty move and I certainly won't be using pixabay moving forward, but the good news is they don't get to sneak into your project and change the license on assets already in use.
More directly addressing pixabay's change specifially, see the discussion on submissions derived from pixabay assets (before their license change) here and here.
TL;DR: Before 1-1-2019, pixabay used the CC0 license. pixabay's new stipulations do not apply to any OGA submission prior 2019. Any assets obtained from pixabay before their license change retain their CC0 status. CC0 cannot be revoked, so pixabay changing their license on CC0 assets is irrelevant. However, you should not download assets from pixabay today and treat them as if they are CC0, since they may not be the same assets as those that were available under the original CC0. Make sure the Published date on the pixabay page is before 1-1-2019.
hehehe! I think if OP is having trouble with tools like piskel for merging 2 sprites, coding something in magic-script may be a bit like using a steamroller to kill a spider. Still, imagemagic is a great tool.
It appears to me the animation is running slower than the movement speed. Try moving the character fewer pixels per move or cycle through more animation frames per move. I understand this may be difficult since you have a set number of animation frames as well as a set distance between tiles. Try working in multiples of your animation frames: if you have 6 frames in a walk cycle, try bumping your animation rate so it renders 12 frames per move (or 2 full walk cycles), if that still looks "slide-y" bump it up again to 3 walk cycles.
You may have to decouple your walking animation speed from movement distance. Make it so as long as the character is moving, the walk animation is running. Then, if the character stops, stop the animation as well and set the characcter back to the standing-still frame. That will allow you to set the animation speed independent of the distance traveled. Once the character stops at their destination, it may jump from a middle-of-a-step frame of animation to a standing-still frame, but it usually doesn't look as unnatural as you'd expect.
If that isn't making sense to you, let me know. Can you make the character spritesheet available here for me to use in demonstrations?
Yes, that method should work for other dimensions just as well. Simply change the values you're entering on step 7. :)
As for how to determine the frame size and offset... Rubberduck explicitly listed 16x16 in the tags for this one, but it's not always so easy.
It involves some guesswork, but this method works pretty fast for me. Most spritesheets have dimensions in powers of 2, so 16x16, 32x32, 64x64 are pretty common. Often the width and height are mixed and matched, though: 16x32, 32x48. On the other hand, there's no rule that says sprites MUST be powers of two, so you'll sometimes encouter sprites with strange dimensions like 21x33. Other times, the graphics is set to conserve as much room as possible, so the sprites are not arranged in a grid (sprite-atlas) but in wherever they will fit.
For example, this pixel dungeon spritesheet (below) has sprites in multiple sizes (16x16, 14x20, 32x32, 35x35, etc) In these cases, no amount of grid tweaking will properly slice all the sprites. Some tools like Unity have texture atlas tools that help auto-slicing the atlas, but other than that, there isn't a good easy way to do it with atlases. Just open it in gimp and start manually cutting each sprite out.
Fortunately, in this example, Zombietom uploaded all of watabou's individual spritesheets in a zip file as well, so there is no need to slice this one image manually: https://opengameart.org/content/pixel-dungeon-graphics-by-watabou
Ah, looks like rubberduck set them up so the overflowing tiles are adjacent. I was wrong about the offsets. It's a 16x16 spritesheet with some tiles having overflow. So, here's how to split them out into individual tiles:
The sprite dimensions for this sheet are not grid-aligned. They appear to be 16x16, but separate sections have different offsets, which makes this more of a "sprite-atlas" rather than a spritesheet. Can you tell me where this came from?
As mentioned in that other tread, I usually use GIMP, though Piskel also does well. It would help us understand what you're trying to accomplish if you would attach the spritesheet you're working with to this topic thread.
licensing flag lifted: patent troll.
@MetroVG Studio Bluebird: This submission has been marked as having a licensing issue while we investigate. Downloads are disabled. Can you provide more information about the circumstances? Please Private Message me links to the documents you've mentioned and/or the relevant JASRAC entries.
Don't be calling it before the finish line; there's 29 people participating and they still have 10 days to submit. I turned in my last jam submission with only 8 minutes left on the timer. :)
Pages