@UberGoober Maybe I don’t fully understand. In your image, the lower left corner of boxes 1 thru 6 have specific x,y values in the sprite sheet. They also have specific width and height values. If I used my program and placed those boxes 1 thru 6 someplace, the lower left corner would have a specific x,y value and the same width and height values. The sprites would be the same size as yours, just in different places. So whatever sprite you get based on it’s x,y values, I would too. I would be using the exact same sprites, just not placed in a specific order.
PS. Where’s the original sprite sheet. I can’t find it.
@UberGoober Thanks, but the first one you sent was good enough. Here’s an example where I pulled 3 sprites from the sheet. I put the 3 of them in a simulated sprite sheet, but I’m really just pulling them from the Project folder. I drew all three of them overlapping on the screen to product the one image of the bee. So it doesn’t matter where the sprites come from, just where they’re going.
@dave1707 okay, but if I understand correctly what you’re trying to do, you’re only showing the part of the process after the orientation work has been done. You’re working from images that someone else has already adjusted to have the blank spaces in the right places for the overlapping to work correctly. When you say “it doesn’t matter where the sprites come from,” you’re technically correct, but I think you’re missing the point that someone’s got to arrange those bee parts and the blank spaces correctly beforehand. In the source files I worked from, @West did that work. When I made my spritesheet, I preserved that work. And in the files you’ve included in this project, the three image files also preserve that work. But the work had to be done by hand in the first place. In this demo you’re not automatically assembling the images in the right place, you’re automatically assembling image files containing parts that someone else already put in the right place.
What you first showed us, at the top of this thread, was an image file that had four smaller images on it. And you demonstrated your program automatically turning those images into separate sprites. Now, if all you started with was an image that had four bee parts on it, you could certainly do the same thing. You could automatically detect the precise bounds of each part of the bee. You could automatically turn each part into a sprite that was the exact size of those bounds. But what you could not do, I think, without some prior information, is automatically generate bounding boxes that were the necessary size, and in the necessary position relative to the sprites, for the overlapping of those pieces to work correctly. If the only information you started with was four images of bee parts arranged randomly on a single source page, you simply can’t generate the same information you get from a hand-assembled sprite sheet, as far as I know.
I mean, even a human has to have some reference to a real bee to get the correct orientation of the bee head to the thorax. A computer also needs some reference to get it right, it can’t do it on its own. So somewhere in the process of creating the bee sprite the human has to somehow give the computer that reference information, whether by hand-programming the parts to be in the right places, or by hand-positioning the parts on a spritesheet. Unless I’m wrong and I always could be, what you have not done, and what there’s no way for anyone to do, is skip the need for a human to manually position those sprites, whether into a single image or inside their own separate image files.
@UberGoober I think your idea of a sprite sheet and my idea of a sprite sheet are different. To me, a sprite sheet is used to hold all the sprites a program might use in a single image instead of having the multiple images individually stored someplace. The sprites are already created in the size and position that are required for the program that uses them. The bee example above is what I’m saying. Someone created those 3 sprites so they could be combined to created the image of the bee. So when they’re put in a sprite sheet, it doesn’t matter where in the sheet they are. When they’re pulled out and displayed on the screen, they form a bee.
My program at the top would take individual sprites already created and allow you to put those sprites at any position in a sprite sheet and pull them back out. It doesn’t require the sprites to be the same size or to be put into a box type area. It’s not meant to take whole images and cut them up into precise pieces. It just holds sprites that are already created.
For instance, you created the above sprite sheet in a 10 x 9 grid with each square being 120x120 pixels. Some of those images are multiple squares next to each other. For instance, the tree trunk is made up of 15 squares. If I created a sprite sheet, the tree trunk would be 1 sprite, not 15. The snail would be 1 sprite, not 3. Same with some of the other images. The sprite sheet is just a place holder for all the already created sprites, not to take an image and cut it up to create multiple sprites. My sprite sheet doesn’t require the bee to be cut up into pieces, but it will hold them if they are.
@dave1707@UberGoober I think you are both right and have different expectations of sprite sheets and their utility. For me sprite sheets are good for collecting together the image assets used in a game in a single file (and I think this can ultimately lead to improved performance by reducing the number of calls on the graphics card). In my opinion the game assets are part of the design process - decisions made in the way to format and present the graphical assets can lead to savings/simplifications on the coding side. This can be particularly true of 2D animations - by choosing a convention of a standard sprite size and relative position within that standard size, the relative position frame to frame is implicit. This requires the person generating the assets to know and stick to the convention. Re-using sprite images from the web, without this prior knowledge, means that adjustments may be required inside the program. So saving time by reusing assets maybe leads to more time expended customizing the coding.
In the bee case, I made decisions to chop up the bug assets into sup-parts to allow me to add a bit of pseudo animation by moving parts independently but also at an early stage my intention was to have bug parts flying off in different directions as it was shot, but this was superseded when I read the explosion tutorial.
@dave1707 I don’t think we have different ideas of what a sprite sheet is.
They have many uses, and your process here is awesome because it can radically shorten the work needed to create them.
It simply can’t eliminate some of the work needed to position sprites correctly relative to each other, that’s all—it can eliminate it in many if not most cases, just not all of them.
@dave1707@UberGoober
there’s been a lot of discussion and code editing here, can someone post the most updated version in a zip? i’d like to dig in to this myself
Okay I’m thinking out how I would use this if I wanted to try to re-do my Foggy Bummer spritesheet using this process. Please let me know if I’m not understanding something.
I’m starting with a bunch of separate files for all the sprites, which is how the original is.
Since my goal is to get the file size down, I need to shrink most of the files to fit inside 120x120 pixels.
To avoid doing every file by hand, what I did before was just drag the full file stack into a single ProCreate file and shrank them all at once that way.
This is kind of where I’m stuck on how I’d use @dave1707’s process. To shrink them all, I had to bring them into one file, but I can’t just send that one file over for Dave’s code to chop up, because once the files are pasted into the larger document they lose their boundary information, which is crucial to the animation. I think the only way to preserve the boundary information is to start from the individual files, and send each file to dave’s process, but if I do that I lose the benefit of shrinking them down. I need a way to both shrink the art all at once and use them with dave’s process in a way that keeps each sprites’ orientation inside its file boundary.
So here’s a question for dave: if I used your code to make a single spritesheet directly out of all the original (large) image files, which would then preserve the sprites’ relative positioning, could I manually scale down that spritesheet to a smaller size and somehow preserve their boundary information at the smaller scale? In other words, could I scale the sheet down and have the sheet still work with your process? That would have solved many of the problems I had.
@UberGoober I wouldn’t waste your time. I don’t think scaling down the sprites would work because you could end up with fractional values which might throw the images off. Plus my program was just an idea and still needs more work. Not sure how well it would work with so many sprites or how much larger the sprite sheet would be compared to the original.