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)
I hear you, but I think people often overlook that developers have practical considerations to take into account. I've gone full tilt with Stipple Effect this whole year, and I have living expenses to consider.
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.
That's fair enough. I guess the additional benefit that I am going for here is that the preview behaviors literally are real-time. The preview window re-computes a preview script's output every time the project state changes in Stipple Effect, so you'll see the effects of a brush stroke on your preview milliseconds after releasing the mouse. That way you don't have to save the file, switch contexts, and see the updated result. But I respect that your current workflow may be your preference.
How does looking at the code expose you to potential legal liabilities? I'm a bit confused by that.
If I haven't paid for a license or even if I have, I don't have permissions to reproduce or use the code. So let's say I'm making a game like Mario paint, and in my game I'm doing some image manipulation.
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.
I get your point in principle, but even if I were inclined to get litigious in a situation like that (which I'm not), I don't see how such an argument would have any legs for anything other than the most niche algorithms in the codebase that concern features or systems are more or less unique to Stipple Effect.
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.
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.
That was a common clause that I encountered while researching the licenses for software with similar distribution models to the one I was targeting.
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 found the name confusing, thinking this was a tool to create stipple effects or implemented a stipple effect algorithm, whereas it's the name given to the pixel art editor. It says so in the title and directly in the repo, it was just my oversight in not properly interpreting it.
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.
Hi abetusk! The first tool I implemented in the program was the Stipple Pencil, which is a variant of the pencil that only colors over the target pixel when the mouse is pressed down, even if the cursor is dragged over other pixels thereafter. The pun was meant to be on that and the term "ripple effect".
However, if I could go back, I'd probably change the name to something more fitting to what the program actually is.
I’m no the target user, I haven’t built games in years, but I loved watching the videos, and your approach of making a sprite editor for doing real work.
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.
Oh it makes total sense, for sure. Sorry if I came across pretending it is simple, it absolutely isn’t.
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.
Hahaha, I've grown to love this question over the past few weeks. I'm a huge fan of Aseprite, and I don't have a bad word to say about 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.
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.
Out of curiosity, is there any workflow that exists for easy imports into Godot?
I personally find that Asesprite Wizard (https://godotengine.org/asset-library/asset/713) has been incredible for easy animation transfer. I'd happily swap to Stipple if something like it exists.
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.
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.
You've got a good eye for form and color, your art is simple but effective (as pixel art should be). I'm in the same boat, so I'm going to buy a copy of Stipple Effect.
Couple of thoughts, as an indie dev:
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)
There's definitely room for an actually FOSS pixel art editor imo. But everyone who makes one wants to sell it for walking around money on itch.io.
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 hear you, but I think people often overlook that developers have practical considerations to take into account. I've gone full tilt with Stipple Effect this whole year, and I have living expenses to consider.
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.
Everyone loves open source, but they pay for commercial products. You deserve to be paid for your work and your product.
Nothing wrong with making paid software! There's definitely a market for it and I wish you well.
I'm just niche and not in your market :D
Fair enough; thanks for giving me something to think about!
Check out Pixelorama
https://github.com/Orama-Interactive/Pixelorama
https://github.com/Orama-Interactive/Pixelorama is FOSS (MIT license) and available for free on itch.io
wow - thanks for the tip! this looks very cool
That's fair enough. I guess the additional benefit that I am going for here is that the preview behaviors literally are real-time. The preview window re-computes a preview script's output every time the project state changes in Stipple Effect, so you'll see the effects of a brush stroke on your preview milliseconds after releasing the mouse. That way you don't have to save the file, switch contexts, and see the updated result. But I respect that your current workflow may be your preference.
How does looking at the code expose you to potential legal liabilities? I'm a bit confused by that.
If I haven't paid for a license or even if I have, I don't have permissions to reproduce or use the code. So let's say I'm making a game like Mario paint, and in my game I'm doing some image manipulation.
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.
I get your point in principle, but even if I were inclined to get litigious in a situation like that (which I'm not), I don't see how such an argument would have any legs for anything other than the most niche algorithms in the codebase that concern features or systems are more or less unique to Stipple Effect.
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.
> 2) what's with the Eula?
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.
That was a common clause that I encountered while researching the licenses for software with similar distribution models to the one I was targeting.
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.
For a free as in free speech pixel art editor, check out LibreSprite (a fork of Aesprite): https://libresprite.github.io/
>asesprite already wires into my engine
Do you mean you have some kind of Aseprite plugin, or are you just hot reloading the sprites?
Asesprite plugin that, for instance, manages all my animation objects
I found the name confusing, thinking this was a tool to create stipple effects or implemented a stipple effect algorithm, whereas it's the name given to the pixel art editor. It says so in the title and directly in the repo, it was just my oversight in not properly interpreting it.
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.
Hi abetusk! The first tool I implemented in the program was the Stipple Pencil, which is a variant of the pencil that only colors over the target pixel when the mouse is pressed down, even if the cursor is dragged over other pixels thereafter. The pun was meant to be on that and the term "ripple effect".
However, if I could go back, I'd probably change the name to something more fitting to what the program actually is.
I’m no the target user, I haven’t built games in years, but I loved watching the videos, and your approach of making a sprite editor for doing real work.
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
Thank you!
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.
Oh it makes total sense, for sure. Sorry if I came across pretending it is simple, it absolutely isn’t.
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.
Hey this is a cool project, but from a selfish perspective: Why would I use this over Aseprite?
Hahaha, I've grown to love this question over the past few weeks. I'm a huge fan of Aseprite, and I don't have a bad word to say about 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!
I linked the GitHub repository in my post; you may also be interested in the following links:
Store page: https://flinkerflitzer.itch.io/stipple-effect
Scripting API: https://github.com/jbunke/stipple-effect/wiki/Scripting
Out of curiosity, is there any workflow that exists for easy imports into Godot? I personally find that Asesprite Wizard (https://godotengine.org/asset-library/asset/713) has been incredible for easy animation transfer. I'd happily swap to Stipple if something like it exists.
Thanks for your interest.
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
Unity issues aside, Godot is awesome! I'd love to see an integration.
That animation with the fish is impressive, it's very difficult to get pixel art to feel natural and organic like that.
Thanks, I appreciate it!
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.
You've got a good eye for form and color, your art is simple but effective (as pixel art should be). I'm in the same boat, so I'm going to buy a copy of Stipple Effect.
Thank you for your trust and for the compliment!
[flagged]
I do. Please stop pestering people about creating stuff you don't like. I don't want to see any more grumpy comment like that.
Eh, I basically play only pixel art games these day.