@Mehmet

Did some final cleanups on the code.

I’m building Typd: a local dictation app. You hold a key, talk, and finished, formatted text appears wherever your cursor is. It runs entirely on your computer in under 2 GB of VRAM or unified memory, works offline, and it’s free.

Why: today’s best dictation apps need the internet, send your voice to the cloud, and ask you to trust whoever’s on the other end with it. And they’re genuinely great. Wispr Flow takes the messy things you say out loud and turns them into clear, well-formatted text. I wanted that without the cloud.

My first attempt was a basic Wispr Flow clone. NVIDIA’s Parakeet (a 0.6B speech model) transcribed locally, then a free cloud API cleaned up the text: removing fillers, fixing structure. Only half of it was local. The transcript still left my machine, and everything depended on my connection. Running the cleanup LLM locally didn’t work either: it needed more VRAM than my laptop had, spilled into RAM, and got slow.

Then I asked: why do dictation apps use two models at all? Every one that explains how it works, Wispr Flow included, describes the same pipeline: a speech recogniser, then a fine-tuned LLM that removes the “um”s, works out what you meant and writes it properly. My guess is that it’s just history. Good speech models and good LLMs both already existed, so apps glued them together.

From first principles, though, the job is simple: audio goes in, finished text comes out. A second model only adds latency, memory and failure points. So why not one model that hears you and writes the final text directly?

That’s Typd. I took an open speech model (Qwen3-ASR) and trained it so it doesn’t just transcribe, it writes: fillers and false starts gone, self-corrections resolved, lists and paragraphs where they belong. All the training so far ran on free GPUs. In blind tests on 66 of my own real dictations (judged by AI judges that didn’t know which app wrote what), Typd was preferred over Wispr Flow 27 times to 12, with 27 ties. It returns text about 0.4 s after I stop talking.

What I’m working on next: structuring long, rambling speech better, and never losing something you said when you correct yourself mid-sentence. The hard part is that big LLMs are good at this because they know so much. A model that can explain anything from the height of the Eiffel Tower to photon spectra can work out what you meant. It’s like having a professor help you write a letter. But you can’t run a professor on a laptop. So Typd teaches a small model just that one skill, distilling what big models do for dictation into something that uses a sliver of your computer.

Typd runs on Windows and macOS, 100% private, no internet needed. It comes in two sizes: a 1.7B-parameter version (about 2 GB) for machines that can spare it, and a lighter 0.6B version (under 1 GB) for everything else.

Added the second boulder and added masks onto the slime and boulders so that the game now knows when you hit a boulder!

Added a boulder that spawns at different gaps in front of you that you can jump over it. It doesn’t have a hitbox yet, so you won’t be penalized for landing on it, but you can jump over it using the spacebar.

Changed the player to the slime, added jumping with space.

I updated the project. I was notified that it initially crashed on macOS, and the arrow keys were a bit janky on macOS as well. All of that has been completely fixed, and I’ve updated the readme and the latest code on GitHub to encompass those changes.

It’s shaping up. I added the characters, changed the title and the icon at the top left,

I’ve set my eyes on controls next.

Added the Blobbe! It just moves forward and loops though. It cant be controlled, YET

Please format the following text to Markdown in your brain.

Blobbe, written B-L-O-B-B-E, is a platformer game that I’m making fully and entirely in Python, Pygame. I have no clue what Pygame is and how it works right now, but I’m gonna look into the docs, look at examples, and figure it out. I hope to build a very nice and cool platforming game to learn more about game development and Pygame itself.

Right now, I’ve built a color-changing rectangle that changes colors five times every second (so every 200 milliseconds). Here are screenshots of it. (I dont wanna open OBS)

Updated README and added a few more features ;)

A few cleanups on the size of the grid.

Today I changed the title card of the window that pops up.

A few other updates:
• I tweaked the final game feel a bit.
• I made the initial spawning star spawn in a sort of light yellow color, and I also added that light yellow color to the colors list.
• I made sure that the window of the simulation is also in dark mode, so you get more encapsulated in it.

Added a background grid so that you get a sense of spatial bigness and tininess. You get a feel for how big and small your orbitals really are.

I finally got the complex merging done.

Before, when an orbital was going too fast, one frame it was at the back of another orbital, and the next frame, it was in front of it. Since its velocity was so high, the radii didn’t ever collide, so it just went through other ones without merging. That was really not acceptable, so I worked a lot on making sure it works.

How I did it is actually very interesting:

1. Get the starting position of the moving object and its ending position on the next frame.
2. Get the coordinates of the target object you want to check for a potential merge.
3. Draw a line from where the moving object started to where it ended, and check if the target object is intersecting that line (calculating what percentage along that line the checked object sits).
4. If it intersects, you merge them.

Cleaned up the repo a

Added some instructions to make it easier, added more colors, and I’m now working on making more rigorous merge logic.

Today I added zooming that works with scrolling up and scrolling down appropriately: when you scroll down, everything gets smaller, and when you scroll up, everything gets bigger. Mass and gravity, of course, stay the same.

I made sure that the sling function (basically spawning new orbitals) works flawlessly. Our aim function—which draws that mini press-and-drag indicator to make it easier to see where you are spawning orbitals—is also working with both camera differentiation and zoom differentiation.

This way, you can zoom all the way out and still spawn orbitals in the correct way, or zoom all the way in and spawn them super close up. All the physics and rendering works beautifully.