I probably won’t post a link every time I make a bugfix, but just in case anyone other than @acedent is actually using the editor at the moment, I’ve made a new release that fixes a crash (which to be fair wouldn’t happen unless you were using fairly massive images), a bug in the output data, and two things that weren’t yet bugs but could have been in the future.
I’m a mac guy, and already have some drawing programs I like, but I gave it a quick spin this morning on the family PC. I may use it when the time comes to export all my images, but I may just end up using Mr. Blinky’s python scripts, since I already have those on my main work laptop.
I do have a couple of suggestions that may make it more feasible for art creation if you don’t feel they bloat the app beyond it’s purpose:
When duplicating a layer, have it automatically set as the active one.
This helps the flow when you want to duplicate, tweak a few frame pixels, duplicate, tweak again, etc
Add keyboard shortcuts for the paint options (brush, bucket, rect, fillRect)
A keyboard shortcut (recommend “x”) for swapping paint colors
Alternatively, allow painting in secondary color with left mouse button. Very tedious to have to leave the drawing area to alternate
I know it’s “vetoed”, but having a new incremental frame name when duplicating would be nice
Same with animations (I know, vetoed). A simple ‘animate’ toggle, that would simply cycle the actively selected frame would be nice. Piskel also allows setting the FPS that it cycles at, which can really help visualize it. It just loops when active, no start/stop.
Having a line tool would also really help a lot. Especially since there’s no dithering (which I find useless at such small frame sizes anyhow). When you do need to dither, drawing diagonal lines, with a pixel offset between them, gets you there fast.
Anyhow, thats my 2 cents. It’s a great start, and could be of good use if only as an export tool, and very light editor.
I’m under the impression that it will compile for Mac, but even if I had the facilities to compile it (i.e. Mono) I don’t have the facilities to test it.
If anyone ever wants to volunteer to compile and test it on Mac though, I’d be fine for them to do that.
How can you be sure which one is the duplicate and which is the original? :P
I’ll look into it, though it’s easy enough to rearrange afterwards with the drag & drop.
Those actually already exist.
P for pixel, F for fill, R for rectangle, O for outline.
I probably forgot to document them in amongst all the other things I had to document.
Again, already exist:
Keys 1, 2 and 3.
The main reason I’m avoiding this is because there’s no clear rule for how it should behave in usual circumstances.
For example, if you duplicate Frame 0 to get Frame 1 and then you try to duplicate Frame 0 again, is that Frame 2 or Frame 1?
And if you have Frame 0, Frame 1 and Frame 2, then Frame 1 is deleted and you duplicate Frame 0, is that Frame 1 or Frame 3?
The easiest options are:
To maintain a counter that keeps incrementing regardless of other frames being deleted
To always produce the number after the frame being duplicated, even if another frame with that number already exists
In a way I think a better number would be to just add an option to name all frames Frame 0 to Frame # by position after the fact, so people can rearrange their frames and then produce the labels for them afterwards instead of trying to do both at the same time.
(Though I can’t imagine anyone will have more than about 8-16 frames at most.)
The main reason I haven’t added that is because Bresenham’s algorithm gives me a headache.
(Unfortunately I can’t use the built-in line drawing because A) antialiasing and B) oddly enough, trying to draw a transparent line doesn’t alter the target image. :P)
If enough people wanted it and would use it then I’d consider it.
That certainly was the original intent.
I get the impression people think I’m trying to match the capabilities Aseperite or Piskel. (Or that I’m simply doomed to be compared to them.)
(Maybe I should have just written an export plugin for GIMP…)
If you activate the ‘bottom one’, that would likely suffice. You could even automatically add new frames to the bottom. While not perfect, it would solve the auto-incrementing issue for newly duplicated frames.
In cases where the user doesn’t want the new frame at the bottom, they can still move it manually and rename as they like, so no loss there that I can think of off-hand.
Would any of this be solved by restricting lines to 45% increments? (I know almost nothing about developing in Windows/Winforms)
You may be doomed. That said, your original scope is just fine, and was communicated clearly enough. Knowing the keyboard shortcuts are in place to me is the biggest issue. Most of my feedback was along the lines of “what would I need here to make this worth drawing from scratch in”, which isn’t the main intent.
First of all, thank you very much for doing this. Sprites editor is a huge help for everyone, who want to make games or interactive adventures.
It’s very simple and has all it needs. The only thing is about preview - can it be implemented in a different window, instead of the frame title in the menu? It would make the drawing of complex characters and objects much easier, even if it won’t be in a 1-to-1 ratio for 16x16 sprites.
Well, that’s two people, so it’s a start I guess. :P
I’m not sure what you mean.
Do you mean inserting data into the ‘data’ field of an FX game?
I don’t really like using Python scripts either, but that’s more because I don’t like Python and don’t tend to keep a copy installed. (I.e. I’m a picky sod.)
Making my own .bin generator is actually something I wanted to do as a separate project, but the use of a SHA256 hash in the data format complicates matters because the program I’d written to talk to the Arduboy’s bootloader was in C++, so I’d either have to rewrite that in C# or find and incorporate a library that handles SHA256. (I possibly could write my own but it would be a big headache.)
If it had just been a bog-standard CRC or something simple like Adler32 then I’d have been fine.
Yes. Unfortunately something more precise would take more than just 30 minutes.
At a later date, when I have more time, I could make a custom control that uses the same kind of rendering as the editor, to ensure that the ‘pixels’ are square. For now I just did something quick and simple.
However, if you drag that grey line above or the grey line to the right, you can adjust the size until it looks square.