Critique => Devlogs & Projects => Topic started by: ProgramGamer on October 13, 2018, 11:40:57 pm

Title: MigSprite, a sprite editor with a focus on animation
Post by: ProgramGamer on October 13, 2018, 11:40:57 pm
Hey there, welcome to my little sprite editor project! ;D

This is a thing I started working on this week, and it's for a tool I've been meaning to make for a while now. The reason for that is that I've noticed a lack of a robust pixel art program out there that also supports animations. Now, the obvious counterpoint to that sentiment is that GraphicsGale exists, but it wasn't made free until last year, and the interface is frankly very dated. Furthermore, it doesn't support project files, which means you have to manually reimport your frames as an animation each time you open the program, which gets tedious when you have more than a few sprites for your game. The tool I currently use is Paint.net, which is excellent except for the fact that its support for animations is nonexistant, bar a small plugin that creates a preview window for single file spritesheets.

My vision for this editor is basically Paint.net with a Flash-esque timeline and proper project files. It will also have an extensive, potentially extendable export system so that it can be used directly and without any middleware to export sprites and spritesheets to a game's files. Ideally, this program would become my main productivity tool for creating graphics for all my games that use pixel art. I'm using C# with WinForms to make it, and I'd be happy to take feedback on any potentially useful features I could integrate into this. If I'm satisfied enough with the end product, I'll probably make it available publicly as well so that other people can take advantage of it. Here's an early screencap to show that this isn't vaporware:


Hope this thread generates some interest in this small project, I could really use the external validation of knowing I'm doing something good. ;)
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: eishiya on October 13, 2018, 11:51:03 pm
What about Aseprite? It seems to have almost all* the features you want for your editor, including a modern UI. It's also under active development, so if there are features that are missing, you could ask for them, or even help implement them.

* It's missing customizable exporting, but I think that's on the road map (they're working on a scripting system for it, which will probably obviate that as a separate feature). The current spritesheet export is already pretty good.
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: ProgramGamer on October 14, 2018, 12:27:05 am
Well, this is going to sound a bit petty and counterintuitive, but I don't like the pixel art UI of Aseprite. Pixel art is great for a lot of things, but UI design is not one of them, especially when that means rounding off the mouse position. It's probably fine feature wise, but it just doesn't feel right, I guess.

Another factor is that I'm a stubborn nerd and I want things my way :P
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: eishiya on October 14, 2018, 01:04:41 am
The mouse rounding might be a screen scaling issue. Aseprite has separate screen scaling and UI scaling, make sure screen scaling is at 100% (and set to UI scaling to 200% or whatever you like). The default settings have it backwards for some reason.

I've seen a few people who dislike Aseprite's pixel art UI, so you're definitely not alone in that. I'm no fan either, but it's not a bother to me since it's just a visual skin on an otherwise convenient UI (at least with 100% screen scaling xP).

UI and workflow count for a lot, so I don't think it's petty or stubborn to want to make your own thing if using/extending existing software isn't a good option.
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: Kiana on October 16, 2018, 02:23:48 am
I think the issues you have with GraphicsGale and Aseprite are potentially solvable:

GraphicsGale does have project files - just go to File > Save As and use the .gal file extension. Furthermore, you can import .gif files, as well as from sprite sheets (although for sprite sheets, I believe each frame will be imported at the same exposure). I donít think thereís much you can do for the interface, unfortunately.

Aseprite has themes if you dislike the default GUI like I do - Minimal Dark (http://ďhttps://2dchaos.itch.io/minimal-dark-aseprite-themeĒ) seems to be one of the most popular themes.

You could maybe try Pyxel Edit as well; the interface seems most similar to PS out of the pixel art programs Iíve tried so maybe itíd be useful. You can work on an animation directly to a sprite sheet, which is a pretty cool feature not many programs have.

But if none of these particularly help your workflow, I donít see any issue with working on your own editor that suits your specific needs, or working on some extensions for existing programs. Itís pretty common to write tools or extensions for streamlining work on larger projects anyways. The only potential downsides to that are the time commitment and any potential knowledge barriers (though Iím sure if you run into any roadblocks, you could get help for them). If youíre not on a tight deadline then Iíd say go for it, maybe you can even make a few bucks selling the program when itís functional.
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: ProgramGamer on October 16, 2018, 07:48:30 pm
Oh, I didn't know GG had project files, that's pretty nice. But yeah, that doesn't really fix the win95 esque interface, so I think I'll pass nonetheless. Pyxeledit looks pretty good actually, but its use case seems aimed more at tilemaps than sprite animations. Not that this is bad in any way, but it's not what I'm looking for or trying to make, so it's a different tool for a different job.

As far as charging money for MigSprite in the future, I'd feel uneasy about doing that. I'd like to keep it maximally available, and charging for it, even a small amount, would mean that those that simply can't pay, such as children or people without credit cards, would be completely unable to obtain it short of piracy. Frankly, I think accepting donations or something to justify supporting it in the long run would be a much better solution to that problem.

Cue five years from now when I inevitable sell out to a big company for big bucks and a candy mansion.
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: Kiana on October 17, 2018, 01:58:36 am
Perhaps you can distribute through the itch.io store? Itís pretty simple to set up a page for your program with optional donations when people download the program. Youíll get some free traffic as well, which is always nice. Of course, that may be a ways off but I got a lot of useful feedback and even some donations posting some game jam/unfinished games there so I figure it might be useful to you.

It does sound like there probably isnít a program that meets your exact specs, and there arenít too many great freeware options around - so it seems like developing this would be beneficial in the long term. Personally, Iím always open to more pixel art program options since I always switch between applications anyways depending on my needs. Best of luck with the project!
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: ProgramGamer on October 17, 2018, 10:20:44 pm
Yeah, itch.io is a good distribution candidate. I actually have a few games and prototypes on it already. Not sure how MigSprite's gonna interact with the way itch sandboxes programs though, but I guess I still have plenty of time to figure that part out. And thanks for the vote of confidence, I appreciate it!

So, in other news, I think I've hit a minor setback. I didn't lose any data or anything similarly dramatic, but I've encountered an issue with the WinForms API that can pretty much only be fixed by changing the way I'm currently making the app.

Basically, WinForms works by creating many small elements called "controls" and assembling them on a canvas. However, what I noticed while testing is that it was pretty slow at zooming and panning the canvas, which is odd for something so simple. I decided to satisfy my curiosity and went down the rabbit hole looking up information on WinForms' performance. And sure enough, it turns out that the reason it's so slow is that every "control" you place on an interface is actually a small window with its own ties to the underlying Windows API. This means that having many controls or drawing zoomed images on a canvas can become very slow, with basically no way of improving this situation while still working within WinForms. And since fluidity is pretty important for a graphic editor such as this one, I can't really leave this unresolved.

Therefore, the way I've decided to solve this problem is to switch to a different Windows API. I decided to go with WPF (Windows Presentation Foundation, an especially nonsensical acronym,) which is basically the new successor to WinForms. What it does differently is it only uses one window handle for the whole program and uses the graphics card as opposed to the CPU for drawing the interface, which is dramatically more efficient than the other way. Plus, a pleasant side effect of this change is that the new way of doing things is much more flexible, meaning I'll be able to personalize the program much more extensively than I could otherwise have.

No worries though, this doesn't mean that I'll be spending an eternity porting everything to the new version. The API for the interface is still similar enough to the old one, and most of the actual behavior code I've written can be copy-pasted almost verbatim since it's all still programmed in C#. This should take at most a few days, especially since it's so early in the project, and it'll make the program better in the long run so I think taking a small time penalty right now is the right call.

Anyway, thanks for showing interest in this project. I hope sharing the process of making this thing ultimately helps me make it better!
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: yrizoud on October 18, 2018, 08:11:31 am
As a fellow developer, I find it dubious that you stumbled on an inherent Winforms issue that will be solved by switching to WPF. Since Windows XP, a hundred of painting programs have been written and used without issue on home computers. I only hope you don't find the same issues in WPF, and then realize it was a mistake such as a cascade of redraws.

Anyway, I wish you luck. Animation is still a topic that doesn't have perfect programs for it - and especially sprite-focused animation.
Layers make everything more complicated, so be sure to know where you're headed. It means you're going to need a very solid UI for timeline. In addition to Aseprite, two programs that do it right are Pencil2d (not really made for pixel art) and z-uo's pixeditor.
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: ProgramGamer on October 27, 2018, 12:00:09 am
Well, I'll be honest and say that I also wanted to switch to WPF because it's a more flexible and modern framework. I felt like I was early enough in the project's lifetime for that to be justified as well. In fact, I've fully migrated everything I had done to WPF now, and it did solve the issue I was having, which means I'm back on track to implementing new stuff!

I'm also aware of the possible complications involving layers and animation, but I don't think they'll be the most difficult features. The hardest one is probably going to be the Undo/Redo system, which I plan on tackling next since I need to build almost every other feature on top of it.

I'll take a look at how the programs you linked do things. Can't hurt to learn from industry experience ;)
Title: Re: MigSprite, a sprite editor with a focus on animation
Post by: ProgramGamer on November 08, 2018, 08:12:08 pm
Hey, just wanted to give a small update to confirm that I'm still working on this, and I want to touch on a few things in this post. First, I want to share where the editor is at feature-wise. Then, I want to talk about my general experience using WPF over WinForms so far, which includes some good things and some less good things. So let's get into it!

First, what's the progress on the editor itself? Since last time, I've added the ability to Undo and Redo changes to the canvas. This is implemented in a relatively rudimentary way since I'm just stacking copies of the canvas for every change made, but I'll make it a bit more efficient at saving memory later on. I've also added the ability to choose colors via a popup window. It's not very ergonomic for now, and it'll hopefully get replaced pretty soon, but it was necessary to have a basic version of this working in order to get the editor in a properly working state. This milestone means that it would be technically possible, although quite unpleasant, to use MigSprite to make actual pixel art. In the current version, the following features are fully implemented:

I know this is a relatively small list of features for an editor meant to be used productively, but it was important to achieve this milestone as a stepping stone for where to go next. The next big step which I foresee is designing the interface and structuring it correctly before too many features make that impractical. I'm currently figuring the design of the tool selector, the color picker as well as the timeline view, and how to take advantage of the WPF framework to help me do that, which leads me to the next thing I wanted to address.

WPF has been very nice to work with so far. XAML is much nicer to work with for composing interfaces than a visual editor or than editing the C# code manually, and the increased styling flexibility as well as a substantial increase in rendering efficiency make it much better suited for the sort of program I'm making. However, it doesn't come without problems, and a big one is the complexity of the framework. Many features in WPF are intended for more complex use cases, which means learning the whole framework takes a lot more effort than I had anticipated, although this would have probably been the same with WinForms.

The feature I'm currently learning how to use is the data binding system. Basically, WPF gives you a mechanism for making sure that the data that represents your program is in sync with what the interface shows you. The complexity in that arises from the fact that, in order to be able to do that, XAML has to interoperate with C#, which leads to some advanced syntax being used and some things being poorly documented. Fortunately, I've found some decent tutorials, and I'm figuring out the relevant bits and pieces by messing around with some test projects I created, but it'll be a while before I have a good mental model for how WPF programs are supposed to be structured, so I think I'll have to rewrite parts of the editor down the line no matter what I do.

Despite the complexity hurdle, I'm still optimistic. I still think this editor is something that needs to exist, and I'm determined to make it happen no matter what. And while WPF is large and complex, it's not infinitely so, which means I'll eventually be able to learn its inner workings with enough time. Until next time, I'm leaving you with the first bit of pixel art made with MigSprite, as well as a screenshot of what the editor looks like right now: