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.
Various bugfixes.
(Most of which was correcting small but somewhat critical mistakes I made when copy-pasting and/or when I was half-asleep.)
Out of interest, is anyone other than @acedent actually using this yet?
I am not currently … but I am really hoping @acedent is reworking all my Karateka graphics! That would be awesome.
Would it secure me a place in team PPOT? 
You probably already have move PRs against our repos than any other contributor.
It would give you that warm fuzzy feeling knowing that you completed Karateka.
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:
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:
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.
That’s what happens already - new frames are added to the end.
Duplicate is an exception because the original frame acts as a reference point, so the duplicate is insterted afterwards.
(My joke was that without looking at the code you can’t be certain whether the duplicate is inserted before or after the original because they’re identical.)
Giving the newest created frame the last available index solves things until the point where the user starts deleting frames, at which point they’ll start getting duplicates.
I could do that, but it feels a bit of a mean restriction.
I might consider it if I don’t have the time/motivation to do it properly though.
The reason that would make it easier isn’t because of the native API though, it’s because I’d know how to do that ‘manually’. (So far I’ve implemented all of the tool functionality manually.)
It’s not really a WinForms specific issue.
Drawing a transparent line will generally end up with nothing being drawn in any sensible API because that’s how transparency is usually expected to work.
(Disabling antialiasing is a bit more API specific, but solving that would be redundant because of the transparency issue.)
I’d better dig a trench and buy a new helmet then.
Fear not, I’ve had them all in since v0.1.0. They were high on my list.
There’s also F2 for renaming and various combinations for save, load, export et cetera. Just no Ctrl+C and Ctrl+V as of yet.
I’m beginning to feel like the creatures features are going to creep in regardless of my intents. ( -_-')
Highlights include:
Hello!
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.
I would suggest something like this:
Thank you for actually using it.
If nobody used it, I’d feel like I’d wasted my time making it.
I’d still like to add an ‘undo’ feature at some point, but it would require a bit of an architectural overhaul.
Again, if I’m going to spend the time and effort doing something like that then I’d want some assurance that people would use the result.
Hrm… This is a fair point.
(It’s a good thing you edited that part in, otherwise my response would have started with “Why?”.)
I’ll put it on my to-do list and try to work on it when I next have some spare time for working on things.
I can think of a way to do it, but the way I have in mind wouldn’t have the tab, it would just be the preview box.
Nice velociraptor by the way. (At least I’m assuming that’s what it is, based on the dew claw.)
It’s really great!! I use it very regularly for tinkering with ideas- not all for the Arduboy.
A ‘killer’ feature to add, would be generating FX resource .bin bundles… this reduces the need to play with python scripts. 
Great, thank you!
Of cause, the tab was just to keep it in the same “design vibe” and the preview box doesn’t really need it.
Yes, it’s velociraptor. Glad you like it =)
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.
Looks great!
Can’t wait to try it with a new feature!
Your 10 minutes of waiting end now:
It works! 
Thank you!
One thing - while stretching the window, the preview box is also get stretched:
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.
