Spyder638 wrote:Also, can someone confirm that exporting and importing files works fine?
Don't work for me. Don't export any file. Working directories are however created. I'm an OSX user.
You can access the animation and import menus by moving your mouse to the left or right of the panel that contains the options.
Terrible decision in usability terms. People shouldn't have to guess (or have any clues) that in those places have there new menu options. It's very recommendable that you let <> onscreen even that very faded.
Spyder638 wrote:Also, can someone confirm that exporting and importing files works fine?
Don't work for me. Don't export any file. Working directories are however created. I'm an OSX user.
You can access the animation and import menus by moving your mouse to the left or right of the panel that contains the options.
Terrible decision in usability terms. People shouldn't have to guess (or have any clues) that in those places have there new menu options. It's very recommendable that you let <> onscreen even that very faded.
Thanks for testing it. Can a windows user confirm this too?
I agree, it's a terrible decision, but please remember this isn't a finished project. I had planned an interactive tutorial which outlines most of the stuff mentioned in the the OP that isn't obvious. There's a lot of stuff quite hidden away if you don't know where to find it.
Spyder638 wrote:I had planned an interactive tutorial which outlines most of the stuff mentioned in the the OP that isn't obvious.
It's a welcomed feature but since app mechanics is very simple don't worry too much about it. The hidden stuff is more worrying. In first beta I give up finding import and animations options after sweep all keyboard.
I also suggest that someday:
- Show RGB of selected color
- Animation options be show in top animation area instead.
Aside the I/O problem things generally work well. Overall you have a nice useful app.
Yup - that's one of the few unfinished bits of the program mentioned in the OP too.
Basically, if you want to save your work for now, make sure to export your frames at the zoom level of 1 - this will export a 16x16 image instead of a 160x160 image, which you can then import fine. Of course, if you want a higher zoom level to make the image bigger, you can also export a larger image in addition to the 16x16 one.
It's definitely very awkward in its current state, I know.
Glad to hear importing and exporting works fine on Windows. Hopefully someone here can fix it for Mac, because I don't have a mac to find out what the problem could be or to know if I fixed it.
Spyder638 wrote:
Glad to hear importing and exporting works fine on Windows. Hopefully someone here can fix it for Mac, because I don't have a mac to find out what the problem could be or to know if I fixed it.
Unfortunately my knowledge of file operation in LUA/LOVE is low. But since I'm one of few osx regular forum users I tend to find quite a few love aps with this kind of Mac incompatibilities in input/files management. Usually happen when using direct I/O Lua commands but as I see from your code you seem to use LOVE proper commands.
Interesting thing. Before I was only trying to save a 2 frame animation, it had a small slowdown/rainbow cursor and then finished (and didn't save at all). But now I asked to save 8 frames and SuperSrite keep more than minutes trying to save. I had even to force quit.
Don't know what could be happen. Or I'm not doing something right. So let me "call" some OSX users to confirm my problem (hey slime, hey jasoco) and some dev (hey robin, hey bartbes) to check if your export.lua have some flaw.
Robin wrote:I'm not a dev, coffee. I just really like to meddle.
Ok sorry then, I just thought that since you doing your sand-boxed SELOVE you should have more than the required knowledge (and deserve also the title of "dev") for this kind of I/O issues.
I think you might actually be using either an invalid filename, or one love can't handle for some reason (utf-8 fails there?), maybe you shouldn't use localized date strings in filenames?
