welcome, mfers
This site has been living on localhost:3069 for too long.
I built mfers.dev when sartoshi left on 6/9 back in '22, but it kinda sucked.
I told u mfers to manually type out URLs to access mfer heads, which got the job done... but it kinda sucked.
Ok, so why not make a simple page to type an ID and download the head image?
well, because that would suck too.
if I'm gonna make a website for mfers, it has to be buttery smooth, fast AF, and fun to use
so what is mfers.lol?
a website for mfers: a collection of tailor-made tools, data sources, and apps for crypto-native stick figures
now, mfers.lol is just getting started, so the hub is sparse. but the foundation is solid, and the seeds have taken root. where this thing goes is up in the air
the tech
ok, here's the good stuff: all of the mfer images on this site are generated in the browser. On first visit, it might take a few seconds to download the layers, but after that it should be buttery smooth and fast AF. I tried to tackle this problem from many different directions, and I think I've landed on a pretty solid approach.
- no need to download thousands of files every time u wanna browse mfers
- using
<img />tags lets u drag and drop them into ur favorite editor - not using
<canvas />for every image saves a ton of memory - using layer spritesheets reduces the network payload by ~10x
- lays the foundation for editable variations of each image (coming soon)
1.) browser images
<img /> url's are intercepted by the service worker, which messages the RCSA worker, which queues the instructions to a pool of OffscreenCanvas instances, rendering the layers via spritesheet bitmaps. the image is encoded to PNG, transferred to the service worker (possibly cached, depending on the image), and streamed to the <img /> tags visible to the user (you).
2.) mfer metadata
10,021 mfers worth of JSON metadata is not small. The raw JSON of every mfer's traits is 7.5MB. It could probably be reformatted to save a few MB, but still, not ideal for quickly loading and iterating through all 10k mfers.
To solve this, I found the minimal possible binary string to encode mfer traits. If two traits can't possibly overlap, I merged them into one 'category' (like 'short hair' and 'long hair'). For every category that's not necessary, a '0' denotes 'none'. For required traits, '0' is just the first option.
The resulting string is 32 bits (4 bytes), so it's possible to store the entire mfer directory in binary using ~40kB.
If you want to take advantage of the mfers metadata, check out mfers.js.
but why?
I've been hanging around since the mfer mint in 2021 and I enjoy making tools for mfers. Some mfers come, some mfers go, but mfers are always up to something.
A global network of stick figures who collaborate on public domain projects is just inherently cool.
what's next?
no roadmap, mfer. I have a couple of ideas, but I don't want to spoil anything.
if u have a suggestion or want to collab on something, shoot me a dm on X.
bugs
if you see a bug or something that could work better, I want to know about it. please shoot me a dm on X with a screenshot and some info about your web browser.