No particular tiles, what I am thinking is that if an automatic quad detector is there ,then we can use any image.
AUTOMATIC QUAD DETECTOR
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: AUTOMATIC QUAD DETECTOR
right aha, so this is sort of like a premature abstraction ?
At times when I was using tiles , usually they are either :
- all the same size
- or accompanied with an extra data file describing how they are laid out.
and more often then not i'd use my own images, so the sizes aren't a mystery to begin with.
I am aware of some tools that are related to your question: if you google something like
But none of these tools do any splitting as far as I know.
The workflow they usually follow is :
- you have a bunch of images possibly of varying size
- a texture atlas tool positions them on an image with as little whitespace possible,
- you use said image and the extra data file describing the layout
At times when I was using tiles , usually they are either :
- all the same size
- or accompanied with an extra data file describing how they are laid out.
and more often then not i'd use my own images, so the sizes aren't a mystery to begin with.
I am aware of some tools that are related to your question: if you google something like
Code: Select all
online sprite atlas
The workflow they usually follow is :
- you have a bunch of images possibly of varying size
- a texture atlas tool positions them on an image with as little whitespace possible,
- you use said image and the extra data file describing the layout
Re: AUTOMATIC QUAD DETECTOR
It can be a special format, make the quad bigger until the magenta border.
-
- Party member
- Posts: 548
- Joined: Wed Oct 05, 2016 11:53 am
Re: AUTOMATIC QUAD DETECTOR
Automatically detecting quads in an arbitrary image like you're asking is possible (assuming you don't take "detect rectangles of certain color" approach with an image like darkfrei's post above), but it would have couple major limitations:
(1) The quads would simply grab the optimum rectangle around the sprite.
This might not sound like an issue, and works if the sprites have exact same dimensions every time. But that's a severe limitation on the kind of complexity those any given animation frames can have. To understand this, consider these few frames of animation:
(Assume gray is transparent, and orange is the bounding box the supposed auto-quad detector would detect)
As you can see, these three frames come from the same animation - but are notably different in how wide they are. This would lead into messy playback of the quads if they're meant to be played in a sequence like the frames above, making the character wobble back and forth and never really staying in the center like they should. To fix this, you'd have to manually write some data file that would track the exact offsets a given quad in an animation should be drawn at, which would be a lot of manual labor in an animation heavy game.
(2) Any animation frame can not have any vertical or horizontal splits in them.
If you consider that third frame of animation from last image, you might spot this:
Now the effect would be considered a separate quad, even though it belongs to the same animation! So, you'd have to be real careful about the things you do with your animations to avoid weird inconsistencies like this. You could split the effect into its separate animation and overlay it on top of the base sprite in your code, but that's not the point here.
As such, your best bet is to follow EngineerSmith's advice: either manually create the sprite sheet and place the quads in predictable manner, or use some tool to package the sprites for you. With the former option, if the largest animation frame is X and Y pixels tall, you'd create a sheet that tiles them according to those dimensions. So those three frames of animation from before would look like this on your manually created atlas:
(the black borders are there for emphasis)
This kind of atlas you can parse pretty easily with some simple code (just grab xyz amount of quads that are horizontally/vertically tiled, starting at given location). Something like anim8 works fine here.
However, as you might see, that wastes a lot of space in the sprite sheet, with a bunch of empty space. This is not too bad if you have low animation counts or not too many sprites in your game, but in a game with a whole bunch of animations and characters? It adds up. That's where the second option of EngineerSmith's suggestion works, so something like Export-TextureAtlas that was linked earlier help. I personally use a custom-made solution involving TexturePacker, but you're free to google around and find another tool that might suit your needs.
(1) The quads would simply grab the optimum rectangle around the sprite.
This might not sound like an issue, and works if the sprites have exact same dimensions every time. But that's a severe limitation on the kind of complexity those any given animation frames can have. To understand this, consider these few frames of animation:
(Assume gray is transparent, and orange is the bounding box the supposed auto-quad detector would detect)
As you can see, these three frames come from the same animation - but are notably different in how wide they are. This would lead into messy playback of the quads if they're meant to be played in a sequence like the frames above, making the character wobble back and forth and never really staying in the center like they should. To fix this, you'd have to manually write some data file that would track the exact offsets a given quad in an animation should be drawn at, which would be a lot of manual labor in an animation heavy game.
(2) Any animation frame can not have any vertical or horizontal splits in them.
If you consider that third frame of animation from last image, you might spot this:
Now the effect would be considered a separate quad, even though it belongs to the same animation! So, you'd have to be real careful about the things you do with your animations to avoid weird inconsistencies like this. You could split the effect into its separate animation and overlay it on top of the base sprite in your code, but that's not the point here.
As such, your best bet is to follow EngineerSmith's advice: either manually create the sprite sheet and place the quads in predictable manner, or use some tool to package the sprites for you. With the former option, if the largest animation frame is X and Y pixels tall, you'd create a sheet that tiles them according to those dimensions. So those three frames of animation from before would look like this on your manually created atlas:
(the black borders are there for emphasis)
This kind of atlas you can parse pretty easily with some simple code (just grab xyz amount of quads that are horizontally/vertically tiled, starting at given location). Something like anim8 works fine here.
However, as you might see, that wastes a lot of space in the sprite sheet, with a bunch of empty space. This is not too bad if you have low animation counts or not too many sprites in your game, but in a game with a whole bunch of animations and characters? It adds up. That's where the second option of EngineerSmith's suggestion works, so something like Export-TextureAtlas that was linked earlier help. I personally use a custom-made solution involving TexturePacker, but you're free to google around and find another tool that might suit your needs.
Last edited by MrFariator on Tue Dec 21, 2021 4:57 pm, edited 1 time in total.
Re: AUTOMATIC QUAD DETECTOR
I'm using this code for ImageMagick:
It takes all images from folder "/Input", detects the alpha and cut the same rectangles from input source and save it as an image spritesheet.
The "idle" source pictures was 68x59 pixels, 10 files, output - one spritesheet 10x1 frames, 380x55 pixels.
Code: Select all
magick "Input/*.png" -background none ^
( -clone 0--1 -layers merge ^
-set option:cropper "%%[@]" +delete ) ^
-crop %%[cropper] +repage ^
MIFF:- | magick montage MIFF:- -background none ^
-tile 10x1 -geometry +0+0 best_spritesheet_10x1.png
pause
The "idle" source pictures was 68x59 pixels, 10 files, output - one spritesheet 10x1 frames, 380x55 pixels.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 3 guests