Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ProgramGamer
Pages: [1]

1
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:



Cheers!

2
General Discussion / Re: Official Off-Topic Thread 2018
« on: October 28, 2018, 07:58:48 pm »
We actually had a worse one on tigs where a korean flower shop spam bot managed to post about 1000 threads in a single day.

3
General Discussion / Re: Official Off-Topic Thread 2018
« on: October 27, 2018, 12:09:01 am »
Uhh, I think there's some spambots having a party lol

4
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 ;)

5
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!

6
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.

7
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

8
Devlogs & Projects / MigSprite, a sprite editor with a focus on animation
« 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. ;)

9
General Discussion / Re: Read the Rules, then introduce yourself here.
« on: October 12, 2018, 01:02:48 am »
Hey, I realized I never actually introduced myself here, so I think I'll do that now.

Hi, I'm ProgramGamer, although some people know me by Miguel. I'm an admin on the TIGSource forums and I'm working on a puzzle platformer called Space Punk Slam Dunk. I'm also working on a sprite editor focused on animation features, though I only started working on that this week as a way to help me make my game.

I hope to have a good time here!  ;D

Pages: [1]