1) Aseprite is already king in this space, yes, this may be more automatable but asesprite already wires into my engine. In my engine, I can write code to preview behaviors in more or less realtime on file save.
2) what's with the Eula? This is not an open source tool, but it appears to be a source available tool with some strict requirements. I cannot distribute the code or binary, which means that even looking at the code could potentially introduce legal liabilities for me. As an indie, not a risk I'm willing to take. (I have this complaint about Aseprite too, fwiw)
It doesn't matter to everyone but it does move the needle for a subset of people. I love to read my tools' source and fork/hack on/contribute to them.
I also don't see how the license prohibits you from doing what you expressed, though that may be an oversight on my part. I'm happy to be educated or listen to what specific concerns you have about how the license or distribution model limits what you would hope to get out of the program.
How does looking at the code expose you to potential legal liabilities? I'm a bit confused by that.
If I've looked at your proprietary code, you could argue I stole your ip to make my game. That the functions I wrote in my game are fundamentally similar to those you wrote, and therefore I need to stop selling.
Most studios have pretty strong "don't look at code you can't own" processes for this reason.
Yea, there's some strange clauses in the eula. For example, the eula stipulates that your operating system must be validly licensed.
> on your computer running a validly licensed copy of the operating system
I don't see how or why this is important at all. In other words, pirated copy of windows is disallowed from using this software.
Not that i have any issues with the eula in general. I think this is good enough to be a paid piece of software. It's just weird to see a clause about the operating system itself.
As far as I can tell, stipulating that end users must be running a validly licensed OS helps protect the licensor (me) in situations where a cracked OS with malware corrupts my software or compromises the whole system.
I think the name comes from trying to be a pixel editor analogous to what After Effect is for video, thus the play on words.
However, if I could go back, I'd probably change the name to something more fitting to what the program actually is.
Many many years ago I built Quake 3D model editors. One of the features added in was being able to paint on the 3D model and have it update the original texture. The ability to make little tweaks to texture in-situ was really valuable to fine tune the art asset.
When I watched the video of Stipple Effect, I loved the live output window showing the result of the combined sprites.
The first thing that came to mind was “If I was the artist I would love to draw I the result window and have it update the input sprites for me”
I fully get the challenges with implementing that, but it might be a valuable addition to the workflow, being able to work on the art with one less abstraction level
That's a really interesting idea, but unfortunately I don't think it would be feasible to implement.
3D model texture mappings are one thing. It is quite straightforward to create a bijection to edit either the texture or the model with the texture applied and have the changes propagate to the other. For my program, 1) this 2D UV mapping texture to animation workflow is only one specific application of preview scripting, and 2) you would have to take additional factors into account besides the texture and the animation in order to implement a two-way function between the texture and animation in 2D. This is because a pixel coordinate from the texture may map to multiple pixels in the animation. These correspondent pixels in the animation may have different color data, and so propagating a change back to the texture would have to account for which pixel was overridden most recently, or a different type of heuristic.
I hope that makes sense.
I guess that’s the role of tool builders - is to find ways to do the impossible to support artist workflows.
The first step is to find out if the end user would even want that workflow in the first place. Maybe it makes no sense, to work that way. But if it is valuable then starts the hard part of figuring out if it is worth the programming acrobatics to implement it.
However, I could attempt to make the case for Stipple Effect over Aseprite a few ways.
In terms of what Stipple Effect can do better than Aseprite, or what it can do that Aseprite can't, I'd highlight some specific applications of the scripting system. If you are a game developer making a 2D pixel art game with a lot of animated assets of the same form (physical shape, dimensions, pose, etc.), Stipple Effect can really expedite the art process.
Imagine you are making a game with tons of NPCs, each of which has to have idle animations, walking animations, and a certain number of action animations. Or a game with significant character customization in the form of clothing and vanity items. At present, you would probably have to individually animate every NPC and every clothing item for each animation. Using Stipple Effect, however, you can spend a bit of time configuring a lookup relationship between a single texture and an animated UV lookup asset, and map the texture to the animation via a preview script. In the long run, this will save hundreds of hours of tedious work, as you will only have to draw a single texture for each item/NPC you are adding to your game.
See this video for a visual aid: https://www.youtube.com/watch?v=Bj1foXYcHl4
Besides that, Stipple Effect is much younger than Aseprite. David has been working on Aseprite for over 20 years as far as I know, while I have been working on Stipple Effect for just over eight months. The program is improving at a much more rapid rate, and will likely receive more substantive updates more often than Aseprite will.
Stipple Effect is only a quarter of the price of Aseprite presently to reflect that it is still a nascent program with less polish, so there is an economic incentive as well.
In summary, I would say you should decide whether Stipple Effect is the best fit for your individual needs, and whether you're willing to take a chance on less proven software with a huge potential upside.
Cheers!
Store page: https://flinkerflitzer.itch.io/stipple-effect
Scripting API: https://github.com/jbunke/stipple-effect/wiki/Scripting
Not presently, but it's definitely something I can look into adding. I haven't used Godot much, but I see the momentum it has behind it (especially since the Unity scandal a few months ago) and it seems like Godot integration will become a more and more coveted feature.
For the time being, I welcome you to drop a comment about it in the feedback section at the bottom of the store page or to submit a feature request here: https://github.com/jbunke/stipple-effect/issues/new/choose
I am by no means a talented artist, and programming comes much easier to me than pixel art. That's a big part of the reason why I made Stipple Effect, which is essentially a program that you can get the most out of when you leverage your skill as a programmer to make making art faster/better/less painstaking.
I will reflect on this though. This is my first time commercially distributing software, and my priorities for the license were for it to protect my IP without being overly restrictive. However, I've had a few people in separate spaces raise concerns with it, and I want my software to be as accessible as possible without compromising my ability to profit from it or expose myself to liability or "theft".
I'm the sole developer of Stipple Effect, so I can update the license with a future release if I feel compelled to do so.
I'm just niche and not in your market :D