heyitsgarrett

Thanks for catching that, went and updated some parts of the engine for touch handling there. It's a bit better, although had to find a bit of compromise. Appreciate it!

I'm slowly easing into wider sharing, but you're really keying in on a dynamic I was hoping to grow within the community, of brush artists and pixel artists collaborating or sharing toys. For right now I'm storing my own brushes as little .txt files.

One feature that is quietly implemented, though - any png you save from MOSS also encodes its brushes. So if you share that png with someone else (or online somewhere!) it can be imported into MOSS with those same brushes and palette. I stole this concept from PICO8, which cleverly encodes all of the game data into a png file.

Added that! Great idea. Hold shift before or during a line draw and it will preview the line, then apply on release.

If you hover next to the brush in the Edit mode as well, theres a tiny pencil icon there that opens that brush's code. Sorry it was hard to discover!

Oh thanks for sharing this! I love asesprite, procreate, pico8 and had this idea for programmable brushes bonking around my head for years now. Recently took some time between projects to put it together.

MOSS is a drawing toy where each brush is a tiny script that knows about every pixel on the canvas. You define how it paints with noise, randomness, patterns, stroke speed, pressure, and every touch executes the code.

So you can have a brush that scatters pixels like a real spray can or one that stamps shapes that mutate as you drag. Or perspective lines that actually converge. Or a fill bucket with smart gap awareness (I called it "Fill of my Dreams" and added to the brush list).

Happy to share brush code in the comments or explore ideas together. There's a (?) in the bottom right toolbar with API docs, and a prompt copy at the bottom if you wanted to work with the API through an agent.

I love asesprite, procreate, pico8 and had this idea for programmable brushes bonking around my head for years now. Recently took some time between projects to put it together.

MOSS is a drawing toy where each brush is a tiny script that knows about every pixel on the canvas. You define how it paints with noise, randomness, patterns, stroke speed, pressure, and every touch executes the code.

So you can have a brush that scatters pixels like a real spray can or one that stamps shapes that mutate as you drag. Or perspective lines that actually converge. Or a fill bucket with smart gap awareness (I called it "Fill of my Dreams" and added to the brush list).

Happy to share brush code in the comments or explore ideas together. There's a (?) in the bottom right toolbar with API docs, and a prompt copy at the bottom if you wanted to work with the API through an agent.

I wrote this article, and appreciate your framing here. A few things contributed to this effect that I think are a bit clearer with hindsight. Central to this was a lack of clarity between designers and engineers about what the state of things actually was. Designers assumed that engineers had been doing some of this work in building shared components, while engineers trusted that designers were aligning with each other. A lot of that happened organically when we were smaller but as we grew faster, those assumptions start to break. Eventually, we were far along before recognizing how much some of our patterns had diverged.

We had a pretty good idea what needed to happen to fix it, but there was a ton of work happening to maintain our same quality at scale across all of our feature teams. When you're focused on maintaining and building toward better reliability, it's harder to slow down and centralize principles, components, etc.

In the end, it's difficult to get people to agree to one thing, much more so when you're adding more and more people to the mix. We're in a much better place now. More than just having an interface library, we've created a framework for debating the various parts of the system and reinforcing that understanding that was missing early on.

Genuine question – who DDoSes Github? From what I've seen, DDoS attacks often seem to be a response to a site or company entering the political sphere in a controversial way.

From their post, they're complaining about Facebook disabling their fan page without explanation while littering the same item with unattributed images.

I've had work in the past posted to their site without attribution and it was a headache to get them to either attribute it or remove it (they chose the latter).

It seems rather obvious why their Facebook account was disabled.