I just found out about this program today! Props for the awesome development. Tried it out on a quick animation of mine and I am super impressed.
However I found a funny bug. I realized that you can put equations into the fields, and generally seemed foolproof until I did a typical QA response of dividing a number by zero and CTDed, losing my project. Hopefully no one else will do something as stupid.
Really awesome program! There are some big problems with being able to actually export PNG spritesheets, though:
the "loop" frames on exported sprite sheets are placed at the very beginning. This offsets the other frames such that the animation no longer actually starts on its intended frame 0. This requires burdensome hand-editing to fix.
it doesn't remember the last selected frames per row. I would suggest making it auto-calculate frames per row that gets it at close as possible to a square with height and width that are each a power of 2 (thus making the resulting spritesheet more performant for use in games).
Most importantly, it just doesn't actually work on my computer--like, at all. It throws the error "Failed to save spritesheet as [directory and name]; Access is denied (os error 5)." The program throws this error regardless of which directory I select for it to export to. Even just exporting directly to C: is too much, apparently. The executable itself has Read and Write permissions, so I'm not sure what's going on here. (I am running Windows 10 Home build 19041.867.)
Thanks for the response--setting an exception in Avast fixed issue #3! :D
While I'm here, I have a few more bits of feedback for you that will dramatically improve peoples' workflow using this program:
in the load spritesheet window, the program should auto-calculate the likely frame width by dividing spritesheet width by frames per row. Making the user calculate this and fill in this field in by hand every time seems like an unnecessary inconvenience. (This won't work with packed spritesheets, of course, but a developer would probably want to process their animations before packing anyway.)
in the load spritesheet window, the program would benefit from a Total rows field below Frames per row. This would allow the program to auto-calculate the likely frame height by dividing spritesheet height by the total number of rows, thereby saving the user the annoyance of checking the spritesheet height and dividing by hand.
spritesheets oftentimes contain more than one animation on them. Since the algorithm is only meant to blend between frames of a single animation, this means a given spritesheet may to be loaded multiple times; and because the program doesn't remember the values last input when loading a spritesheet, the user has to input them by hand over and over. To fix this, the program should probably just remember the values last used when loading a spritesheet.
when loading a spritesheet, the program should probably remember the filename of the loaded spritesheet and--when going to Export spritesheet--fill that same filename in by default rather than making the user type it (or a variant of it) out in full every time.
the increase/decrease arrow buttons to the right of the FPS text field don't respond to clicks.
Thanks for a great program; I look forward to seeing it develop further!
I love this but it won't let me export - I keep getting an OS error 3? "System cannot find the path specified"
Also - is it possible to set a default folder where I could export to? It keeps trying to save to the program files folder - in the Gamesfromscracth video - Mike exports to his desktop?
Try placing the program into another folder (including all other included files), e.g. put it in your Documents folder, then try exporting again. (If you put the program in Program Files you may run into permission issues so don't do that).
The default export folder is the location where you extracted the zip file and ran the program.
Update: turns out this is a bug, you can fix it by ensuring that Bitmapflow and your export folder are on the same drive. (e.g. both paths start with C:/)
If I try DenseRLOF on a low resolution Sprite sheet, it will not progress and the complete percentage will stay at zero, and crash the software. I purposely crashed it with task manager open and the memory of the software skyrocketed to 4,000 MB. I had to close it out in task manager before it got too full. SimpleFlow works fine though and the program is crazy useful.
That's a known issue, this is an issue in the library I'm using so I can't do anything about it. Although I guess I could add a minimum sprite resolution...
I can't get it to load anything. If I choose spritesheet and select an image, it says the image is "0x0" dimensions and nothing loads. Same with GIF - nothing displays.
I don't get any error messages or anything. Not sure what's wrong.
I tried loading some images as individual frames, and yes that worked immediately.
But trying to load as "sprite sheet" gives me the sprite sheet import window, but the area where the sprite sheet should be is blank, and the image dimensions listed as "0x0" in the corner.
And similar with loading GIF, except the "before" and "after" windows are just blank.
Seeing as the Individual Frames mode works fine, my guess is that this is some sort of bug.
EDIT: I found out exactly what's causing the problem.
I had a hunch it might have to do with different Drive Letters, and it does. I like to place my portable apps on an external thumb drive located at "Z:\TOOLS\" so this program would be located in "Z:\TOOLS\BitmapFlow\BitmapFlow.exe"
If the program is on the "Z:" drive, it won't load any images from the C:" drive, or any other drive. But if try loading a GIF or Sprite Sheet from the "Z:" drive, it DOES import correctly!
To confirm that it was indeed an issue with the drive letter, I copied over BitmapFlow to the "C:" drive -- to "C:\BitmapFlow\" precisely.
Once it was in the "C:" drive, the exact opposite happened, as I predicted -- only GIFs and spritesheets from the "C:" drive would load, and it would no longer load images from the "Z:" drive.
So there's a bug in your code when reading files where it assumes that the files loaded are on the SAME drive letter as the program itself. So if I have your program located at "Z:\TOOLS\BitmapFlow\BitmapFlow.exe" and try to load a file located at "C:\test\sample.gif" -- my guess is that it tries to load "Z:\test\sample.gif" instead -- which this file path doesn't exist, so it fails to load anything (thus a 0x0 image dimension).
Oddly, this bug doesn't seem to happen when loading as "individual frames". So you may have either used a different code there, or fixed it there and not ported the fix to the other methods.
You should be able to test all of this if you try running the program from a USB drive -- or try loading GIFs from a USB drive that isn't in the same letter as the program.
Update: just tested, can you try using drag and drop instead of loading a file from the file menu? Drag and drop does seem to work for me, but loading from the file menu is indeed broken if the file's on another drive.
That's definitely an issue with most programs, generally. But that's not the issue in this case. I was able to figure out the issue and posted about it in another reply.
I waited so long for something like this. All the other auto tween software was either waay too expensive or difficult to use. This kind of software helps people with wrist strain and time restrictions so I needed it, and I do hope it will continue to develop.
← Return to tool
Comments
Log in with itch.io to leave a comment.
但是虽然没有用过，但是看介绍，是一款很棒的软件！
I would pay for the Mac version (not very motivated to install rust on my machine :/)
I just found out about this program today! Props for the awesome development. Tried it out on a quick animation of mine and I am super impressed.
However I found a funny bug. I realized that you can put equations into the fields, and generally seemed foolproof until I did a typical QA response of dividing a number by zero and CTDed, losing my project. Hopefully no one else will do something as stupid.
Awesome!
Really awesome program! There are some big problems with being able to actually export PNG spritesheets, though:
About 1 and 2: I'll look into it.
About 3: have you tried:
Thanks for the response--setting an exception in Avast fixed issue #3! :D
While I'm here, I have a few more bits of feedback for you that will dramatically improve peoples' workflow using this program:
Thanks for a great program; I look forward to seeing it develop further!
Thanks for the great feedback! I'll be sure to write it all down.
Wow, cool as ice dude, thanks for making life a bit easier. Cheers. Just had to add an exception to Avast to get it to save output.
please please please a linux version OwO
Working on it.
and a mac ver pretty please ^_^
I love this but it won't let me export - I keep getting an OS error 3? "System cannot find the path specified"
Also - is it possible to set a default folder where I could export to? It keeps trying to save to the program files folder - in the Gamesfromscracth video - Mike exports to his desktop?
Try placing the program into another folder (including all other included files), e.g. put it in your Documents folder, then try exporting again. (If you put the program in Program Files you may run into permission issues so don't do that).
The default export folder is the location where you extracted the zip file and ran the program.
Update: turns out this is a bug, you can fix it by ensuring that Bitmapflow and your export folder are on the same drive. (e.g. both paths start with C:/)
I'll publish a fix for this soon.
Thanks for the reply, I'll give that a try.
Version v1.0.1 is now available, it should fix this bug.
If I try DenseRLOF on a low resolution Sprite sheet, it will not progress and the complete percentage will stay at zero, and crash the software. I purposely crashed it with task manager open and the memory of the software skyrocketed to 4,000 MB. I had to close it out in task manager before it got too full. SimpleFlow works fine though and the program is crazy useful.
That's a known issue, this is an issue in the library I'm using so I can't do anything about it. Although I guess I could add a minimum sprite resolution...
Got it, I'm not sure if said min sprite resolution is different depending on the system, maybe you could do something check for a "memory overload".
Looking forward to the Linux version :)
I can't get it to load anything. If I choose spritesheet and select an image, it says the image is "0x0" dimensions and nothing loads. Same with GIF - nothing displays.
I don't get any error messages or anything. Not sure what's wrong.
1. Have you tried loading individual frames too? Does that work?
2. Do you have an antivirus active? If so try disabling it.
I tried loading some images as individual frames, and yes that worked immediately.
But trying to load as "sprite sheet" gives me the sprite sheet import window, but the area where the sprite sheet should be is blank, and the image dimensions listed as "0x0" in the corner.
And similar with loading GIF, except the "before" and "after" windows are just blank.
Seeing as the Individual Frames mode works fine, my guess is that this is some sort of bug.
EDIT: I found out exactly what's causing the problem.
I had a hunch it might have to do with different Drive Letters, and it does. I like to place my portable apps on an external thumb drive located at "Z:\TOOLS\" so this program would be located in "Z:\TOOLS\BitmapFlow\BitmapFlow.exe"
If the program is on the "Z:" drive, it won't load any images from the C:" drive, or any other drive. But if try loading a GIF or Sprite Sheet from the "Z:" drive, it DOES import correctly!
To confirm that it was indeed an issue with the drive letter, I copied over BitmapFlow to the "C:" drive -- to "C:\BitmapFlow\" precisely.
Once it was in the "C:" drive, the exact opposite happened, as I predicted -- only GIFs and spritesheets from the "C:" drive would load, and it would no longer load images from the "Z:" drive.
So there's a bug in your code when reading files where it assumes that the files loaded are on the SAME drive letter as the program itself. So if I have your program located at "Z:\TOOLS\BitmapFlow\BitmapFlow.exe" and try to load a file located at "C:\test\sample.gif" -- my guess is that it tries to load "Z:\test\sample.gif" instead -- which this file path doesn't exist, so it fails to load anything (thus a 0x0 image dimension).
Oddly, this bug doesn't seem to happen when loading as "individual frames". So you may have either used a different code there, or fixed it there and not ported the fix to the other methods.
You should be able to test all of this if you try running the program from a USB drive -- or try loading GIFs from a USB drive that isn't in the same letter as the program.
Thanks for letting me know, I'll look into it.
Update: just tested, can you try using drag and drop instead of loading a file from the file menu? Drag and drop does seem to work for me, but loading from the file menu is indeed broken if the file's on another drive.
This should now be fixed in Bitmapflow v1.0.1.
I just downloaded the new version and tried it out. File loading definitely works now! Thanks for the quick fix! This is a pretty useful app.
Don't load the image from a zip file, extract it first
That's definitely an issue with most programs, generally. But that's not the issue in this case. I was able to figure out the issue and posted about it in another reply.
Fantastic now I can make all those rpgmv sprites go from 3 steps to 9 steps.
I waited so long for something like this. All the other auto tween software was either waay too expensive or difficult to use. This kind of software helps people with wrist strain and time restrictions so I needed it, and I do hope it will continue to develop.
I can feel you bud, my carpal tunnel has gotten so bad, I always end up procrastinating
Yeah it sucks to have wrist problems when you really want to still create. I do hope this type of tech. will help though.
When I save the animation, it shows this error: "Failed to save spritesheet (os error 5)".
Does it work when you save an animated gif? And what about individual frames?
No, it does not work at all neither for animated gifs nor for individual frames. I can't save anything.
That's strange... Are you running out of disk space, perhaps? Or are you on a computer with restricted privileges? (e.g. a school computer?)
Ok, now I found the problem! It was my antivirus that blocked the saving process. I'm sorry if I thought this was a bug of your software.
It's okay, glad you solved it!
I had the same problem, had to add an exception for the bitmapflow folder in Avast Antivirus program. Cheers for the hint.
Tested it on a 3 frame sprite and...
This is ABSOLUTELY insane!
Thank you so much for making and sharing this.