-
Notifications
You must be signed in to change notification settings - Fork 785
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding spritesheet import - fixes #188 #284
Adding spritesheet import - fixes #188 #284
Conversation
CodeMooseUS
commented
Jun 1, 2015
- Updated the import dialog to allow users to specify the number of frames in the source image (which defaults to 1 x and 1 y)
- Setting the frame count for x and y will draw a dotted line in the preview that shows where the image will be split into individual frames
- Changing the frame count will also auto adjust the image width/height so that it displays the size of an individual frame, which can then be manually changed to resize the resultant frames into the desired final size
- When imported with a frame count above 1, the source image will be split into the different frames and loaded just as if it were an animated gif
- This allows users to import existing spritesheet pngs, including those produced by the piskel export function (additional work will be needed to specify the frame layout on export - right now a 'square' layout as shown in the image below will still be exported as a single horizontal strip)
- Updated the import dialog to allow users to specify the number of frames in the image (which defaults to 1 x and 1 y) - Setting the frame count for x and y will draw a dotted line in the preview that shows where the image will be split into individual frames - When imported with a frame count above 1, the source image will be split into the different frames and loaded just as if it were an animated gif - This allows users to import existing spritesheet pngs, including those produced by the piskel export function
- My editor added additional whitespace to several unchanged lines, so I just reverted them
- The width/height of the canvas used to draw the frame grid in the preview was incorrect, so the stroke width was too thick - This change fixes it so the stroke width remains nice and thin by applying the correct canvas size
Thanks a lot for your contribution. The code change looks good to me, that's great ! I tried out the feature and I just have one comment : many spritesheets I find have some padding on the right/bottom of the image. I was wondering if we shouldn't go the other way around, and ask for a frame size. User could specify the expected frame width/height, and adjust it using the grid preview you developed. We would then ignore empty/incomplete frames during the import. But maybe I was just unlucky with the spritesheets I found ? |
You are right, I guess a lot of spritesheets are packed into images that are powers of 2 in size, which is fine until the actual frame size is not fully divisible by that, as with your example. Mostly I tend to work with frame sizes that are powers of 2 themselves (16, 32, etc) as I know I'm going to be packing them together, so I didn't think about it. I guess the better approach is to (as you say) allow to user to specify the frame size, and a possible offset value, and only split into frames where it can fit a full frame of that size (leaving out the gap at the right/bottom). What are your thoughts on the UI for that? Add a new checkbox for 'split into frames' and if checked, reuse the 'Size' as frame size, and have what I've currently got as 'Frames' to be 'Offset' instead? I could potentially add a checkbox for 'ignore empty frames' in case people want to keep the empty ones for some reason, but maybe that is overkill. I'll take a look later and see what I can come up with. But any ideas you have would be great. |
Ultimately I think the image import and spritesheet import could be really separated.
What do you have in mind for the offset ? If there is padding on the top/left of the image, and not only on the bottom/right ?
I tend to agree, it's an overkill, let's just skip the empty or incomplete frames. |
- The import dialog now allows users to select an option between single image or spritesheet importing - The spritesheet option allows setting of the size of an indivdual frame and the offset from the left/top from which to start slicing frames - Selecting the spritesheet option will display a frame slice grid over the preview image to give a quick view of where the frames will be made - When importing the spritesheet blank (transparent) frames and also partial frames will be ignored - This allows users to import spritesheets that have been packed into a larger image with excess padding
Also - Thanks for the great tool, I love this thing :) |
That looks really great ! 👍 Made a few comments in the review, if you still have energy to spare :) It should be ready to merge after that. 💡 Food for thoughts : even with the grid, it can be difficult to spot the "good" sprite size. Any ideas on how we could make this easier ? Maybe a live preview of the import ?
That's really nice to hear ! Thanks a lot for your contribution :) |
- Using labels for the import type radio buttons - Non animated gifs can now be imported as a spritesheet - Fixing frame slicing to ignore a partial frame while looping
Thanks. I've updated the code based on your feedback. A live preview would be a nice addition. I guess the workaround right now is to just import again until you get it right? So not too bad I hope. Shouldn't be an issue for sheets you've made yourself though, as you already know the size. |
Looks good to me, merging ! (Do you have a twitter account ? I'd like to mention you when announcing the release on twitter, if you're ok?) |
Adding spritesheet import - fixes #188
I don't really use Twitter. Feel free to say "github user JALissiak" or something. But it's not necessary. Just glad I could be useful :) |