Starforge
- 4 Devlogs
- 29 Total hours
A multiplayer pixel art & animation studio that runs entirely in the browser
A multiplayer pixel art & animation studio that runs entirely in the browser
⭐ Starforge is a pixel art editor that runs in your browser. No engine work today, since I focused on a more important point: Whoever opens starforge.lacorte.city from a feed post, leaves in about two minutes, with no instructions and usually a phone in their hand, so the whole day went into that first visit. You can start your own document now insted of only erasing the star, your drawings survives a reload, and on a phone the layer panel became a drawer.
Most web editors take your drawing with them when they break. This one doesn’t. When a component throws, an error boundary renders a screen where Export PNG still works, if the editor dies, you get the PNG out before you reload.
Two reasons that’s possible. The document never lived inside the component that broke: it belongs to the DocumentSession, outside the render tree. And the export never goes through the editor, it composites the frame straight from the document. The thing that holds your art and the thing that failed are not the same thing.
Tomorrow morning the first real ship goes out :D
⭐ Starforge is a pixel art editor that runs in your browser. Yesterday it could only draw in a single surface. Today the same old star is five stacked layers, carrying its own opacity, visibility and lock, plus a rule for how its colors blend with the layers below.
Compositing every layer on every frame can’t hold 60fps. At 256x256 with eight layers at 800% zoom that’s eight blits of 2048×2048 per frame, about 33 megapixels of work to show a picture that didn’t change. So the editor composites once per change into an offscreen canvas, and the screen just draws that one image. Rendering with no cost since that nothing changed.
All with 169 green tests.
⭐ Starfoge: A multiplayer pixel art & animation studio that runs in your browser.
Day three, and it finally draws! The whole toolbox landed with six drawing tools and keyboard shortcuts already known by pixel artists. Yesterday’s 37 green tests are 117 today.
Today i want to deep dive in one of the questions i had: why fast strokes come out dotted. The browser only tells the page where the mouse is once per screen frame (~60fps), but a hand can cross half the canvas between two of those reports and a quick zigzag would become a trail of separated dots.
The fix comes in two layers:
First, the browser actually keeps the positions it skipped and hands them back in a bundle with each event, so I ask for those in-between samples.
Second, even those have gaps when the gesture is really fast, so between every pair of samples I draw a tiny line using Bresenham algorithm, the same grid walker my line tool uses, it steps from one pixel to a touching neighbor and can’t skip a cell by construction. So every stroke you see is secretly dozens of tiny straight lines, stitched end to end.
Tomorrow i will start landing Layers to our studio. Thanks for reading and see you on the next devlog :D
⭐ Starforge is alive in the browser! This is day two building a multiplayer pixel art studio. So far the editor opens with a little star, and every pixel stays razor sharp at any zoom. With 37 green tests I already started coding the first drawing tools (pencil, eraser, bucket).
The sharpness comes from a two stage blit with shared memory. A sprite’s pixels live in one Uint8Array wrapped in an ImageData view, using only one buffer for model and image bytes. Stage one pushes just the changed rectangle onto an offscreen canvas (1:1) which ignores scaling and smoothing so it never blurs. Stage two is a single draw image that stretches the offscreen canvas to the current zoom with the GPU doing the nearest-neighbor upscaling for free. When the pencil lands next ship, the bytes it writes are already the bytes the renderer reads.