AuthorTopic: MigSprite, a sprite editor with a focus on animation  (Read 4395 times)

Offline ProgramGamer

  • 0001
  • *
  • Posts: 9
  • Karma: +0/-0
  • The Programmer of Games
    • ProgramGamer
    • View Profile

Re: MigSprite, a sprite editor with a focus on animation

Reply #10 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:

  • File Loading and Saving
  • Drawing and Erasing
  • Canvas Resizing
  • Color Picking
  • Undo/Redo capability

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:

« Last Edit: November 08, 2018, 08:14:57 pm by ProgramGamer »