tgergo1.dev

Oct 15, 2026 21:00 1792098000 dna H=4.7

Aeneas Factory: an asset factory on a Mac that AI agents can use safely

ai gamedev tools open-source

Games need a lot of stuff: props, textures, little sounds, a voice line here and there. I wanted my AI agents to be able to make those for me, on my own machine, with open models, and without me having to check every file by hand. So I built Aeneas Factory.

It generates images, seamless textures, textured 3D models, sound effects and speech locally on an Apple Silicon Mac. Every model is open, pinned and checksummed, and nothing leaves the machine after the downloads. It’s open source, under MIT, on GitHub. This post describes version 0.2.1.

That chest is the gallery in one picture. Z-Image Turbo made it from a sentence. FLUX.2 [klein] repainted it from the instruction “paint the wooden planks a deep blue, keep the iron bands, the brass lock and the white background”. TRELLIS.2 turned the first picture into a textured, UV-unwrapped 3D model, rendered here in Blender. All three came out of one command each, with fixed seeds, so anyone can make them again.

Built with DINOv3. The 3D models in this post (the chest on the right above and the bucket further down) were made with TRELLIS.2, which uses Meta’s DINOv3 image features under the DINOv3 License.

A failure is never a success

The thing that made me build it properly was a blank image. The Metal VAE decode in the stable-diffusion.cpp build I use returns plain white pictures, and the first version of this repo happily reported them as successes. An agent would have taken that and moved on.

So now every output is checked before it counts. Images are checked for being blank or flat, tiles for visible seams, sounds for silence, meshes for being empty or flat. A failed check is an error, never a result.

On top of that, --candidates N makes several, drops the failures, ranks the rest by how well they match the prompt (SigLIP for pictures, CLAP for sound) and keeps the best. All the candidates stay on disk.

Every file says how it was made

Each file carries its own record, inside it and beside it: the PNG text chunk, the glTF extras, the WAV INFO block, and a .json next to it. The record lists the models with every file’s SHA-256, the versions of the factory and its tools, the prompt, the seed, the settings, the checks it passed and the licence policy that applied. Whenever I find an asset later, I can tell exactly where it came from.

Licences are handled per project. A small policy.toml says which licences and models a project allows. One of TRELLIS.2’s parts, the DINOv3 features, is under Meta’s own DINOv3 License, so it only downloads after you accept it, and a project has to allow it before it’s used. That licence allows commercial use, asks for “Built with DINOv3” to be shown wherever DINOv3 or its derivatives are distributed, and rules out military, weapons and espionage uses. Every 3D model the factory makes carries “Built with DINOv3” in its provenance and credits.

Model cards matter too. Image ranking used to run on OpenAI’s CLIP, but its model card puts any deployed use out of scope, so the factory now ranks with SigLIP (Apache-2.0). The records state licences as the model cards give them, which is not legal advice.

Finished assets, not raw generations

Most of the real work sits between the model and something a game can actually use. Recipes do that part: several steps in a row, every intermediate kept, one manifest at the end.

The prop recipe made that bucket. It picks the best of two concept images, turns it into 3D with TRELLIS.2, and then Blender makes it 0.4 m tall, puts its origin at the bottom and cuts its 149,556 faces down to LODs of 20,000, 10,000 and 5,000. That took 11.6 minutes. The sprite recipe cut the key out onto a transparent background with BiRefNet. The cobblestones are a seamless tile, shown here 2x2, and they come with height, normal, roughness and AO maps.

Sounds go through the same mill. This is the chest lid creaking open and thudding shut, from MOSS-SoundEffect:

The sfx recipe goes further: two takes ranked by CLAP, silence trimmed, loudness set to -18 LUFS. You can listen to the chest and the door on GitHub.

Built for agents

The point of all this is that an agent can use it without supervision. Claude Code or Codex connects through an MCP server with sixteen tools: generate an image, make a texture, turn a picture into 3D, make a sound, run a recipe, search the library, read a file’s provenance, and so on.

Every result comes back with a thumbnail the agent can actually look at: the image, a 2x2 tile, a render of the model, or a waveform. Long jobs like 3D return a job id straight away. And the agent can’t do anything dangerous with it: the server never runs code it is sent, never downloads models, and only writes under your home folder, outside the factory.

Underneath there is one factory service per machine. It owns the GPU with a single queue, so two agents can’t start two jobs at once and run out of memory. It keeps the sound model loaded between jobs and listens only on 127.0.0.1, with a token, refusing anything that looks like it came from a web page. The MCP server, the aen command line and ComfyUI all go through it, so the checks, provenance and policy apply the same way everywhere.

There is also an asset library that remembers everything generated or imported (a downloaded CC0 pack, say), searchable by words and, for images, by meaning. aen library credits writes a project’s credits page from it. Style packs keep a project’s look consistent across every asset.

Under the hood

The engines are stable-diffusion.cpp for Z-Image Turbo and FLUX.2 [klein] 4B, trellis.cpp for TRELLIS.2, and MLX for MOSS-SoundEffect and Kokoro speech, plus Real-ESRGAN, BiRefNet, Blender and ffmpeg. ComfyUI is an optional engine and a playground, reading the same model files in place. The four core models are 40.5 GB together; make install GROUPS=image gets you started with just the image ones.

On my M5 Pro a 1024 px image takes two to three minutes, three 512 px candidates ranked by prompt match take 75 seconds, and a 3D model takes about five minutes.

It’s Mac only for now. The MLX parts (sound and speech) are Apple-only. The image and 3D engines also build on Linux with NVIDIA, but I haven’t tested that. If you try it, I’d love to hear how it goes.

read more →
permalink → ♡ react ○ comment ↗ share
Oct 15, 2026 20:30 1792096200 dna H=4.6

Újhon: a medieval village that remembers

gamedev games unreal simulation

I’ve been building a game called Újhon. It’s Hungarian for “a new home” (say it OO-y-hon), and it’s a medieval village builder about the people who live there.

Your households arrive in a clearing in the wildwood with a tent, a fire and a winter coming.

Every one of them has a name, a family and a trade. They fell the trees, haul every log and sack on their own backs, raise the houses you mark out, farm, fish, bake and brew, marry and grow old. Nothing appears out of thin air: every log and every sack is carried by someone.

A village that grows like one

What I wanted most was villages that look like real ones, not like a grid. In Újhon you can put a building anywhere, at any angle. It turns to face the road beside it and puts its door on it. Streets bend, lanes meet at odd corners, and the ground people walk most becomes a trodden way that the next house stands beside.

Doors, gates and fences matter. Every errand ends at a door or a gate, finished houses are solid, and fields are fenced with one way in, so where you build decides how far everyone walks. Fields and kitchen gardens you draw yourself, and the fence is priced by its length.

There are more than sixty kinds of building, and each one is rebuilt through up to five levels as the manor prospers, from a hide shelter to a timber-framed house to a stone hall. That’s 285 models, every one of them modelled in code in Blender. Houses also get variants, so a row is never one house repeated.

To get the plots right I went back to surveyed medieval plans (Stratford, Alnwick, Alresford, the Scottish burghs, Wharram Percy) and measured the game’s villages against them. A house’s yard is furnished by its household: a water barrel by the back door, a rick in winter, a burgess’s crates and barrels.

The year turns

The calendar is the medieval one. You bring in the harvest before the weather turns, put wood by for the winter, and keep fifteen feasts through the year: a maypole on May Day, bonfires at Midsummer, carved turnips on All Hallows’ Eve, holly and candles at Christmastide.

Under the hood

Újhon started as a game I built in Godot, called Feudal. This version runs on Unreal Engine 5. The simulation is a C++ port of the Godot one, engine-independent C++20, and it reproduces the original bit for bit: the random numbers, the hashing, the sorting, the pathfinding, the noise. I checked it by replaying 100 weeks in both and getting the same state hash. Since then it has changed on purpose (buildings off the grid, doors, walls that stop people), but old saves still load.

The whole thing is deterministic, so every machine agrees and a save reads back exactly. That is also what makes it testable: thousands of automated checks run on every change, and I stand up whole towns of a thousand people and play them for years to find what breaks.

Much of the code and some of the art were made with the help of AI tools, Claude among them. The game itself generates nothing with AI while it runs.

Újhon is heading to Steam as Early Access in 2027, on Windows first and macOS later. I’ll post the store page here when it’s up.

read more →
permalink → ♡ react ○ comment ↗ share
Oct 15, 2026 20:00 1792094400 dna H=4.5

Cozombie: a cozy game about the end of the world

gamedev games mobile

I made a game. It’s called Cozombie, and it’s a cozy idle game for iOS and Android about restoring shelters after the end of the world, and keeping the dead out of them at night.

You find a ruin, clear it out room by room, wire in some lights and slowly turn it into a home. The first one is four dry rooms slung under a dead highway bridge.

Every room goes through the same stages: clean up, repair, power, furnish, make it cozy. Finishing a room switches on its perk. A bedroom sleeps two, a workshop builds faster. Cozy shelters attract survivors, each with a name, a knack and a favourite thing. They wish for things (a bath, a kite, a look at the sea), make friends and eat supper together at dusk. Sooner or later a cat turns up.

There is one rule the whole game hangs on: the dead go to the brightest light. Not to people, not to noise. And you are the brightest light. The first lamp you switch on is seen for miles, and the cozier your windows get, the more of them come looking.

So by day you build and prepare. Every few nights they come as a crowd, along your barricade, and the forecast tells you how: all from the left, runners first, a screamer leading. There are ten kinds, and each wants a different answer. Whatever your turrets and the night watch don’t stop, you tap. Rain thins them, fog hides them, and a night of snow needs a stove and wood put by.

When you move on, the shelter you leave becomes a bakery, a timber yard or an infirmary and keeps sending you what it makes. There are twenty shelters on the road north, from a nook under a bridge to a lighthouse, a stranded ferry, a snowbound lodge and a vault in a mountain. Each one learns a trick of its own: the lighthouse beam slows whatever it sweeps, the crane drops a container on the thickest of the crowd.

There is a story too, told in small pieces between jobs: a woman on the radio at the end of the road who counts your lights, notes signed “M.” left by someone a few days ahead, letters from the people you left behind. Piece by piece you find out what happened at ten past four, six years ago, and what the beacon in the mountains is for.

And on the nights nobody comes, there are marshmallows round the fire pit, cocoa on the sofa and stargazing from the watch tower. Or you can just sit, hide everything, and watch the rain on the roof.

The first three shelters are free for as long as you like. One purchase opens the rest of the road. No ads, no timers, no account, and nothing leaves your phone.

It’s built with plain JavaScript and Capacitor, with the scenes rendered and the lights, weather and night sky drawn on top as SVG. It’s on its way to the App Store and Google Play. I’ll post here when it’s out.

read more →
permalink → ♡ react ○ comment ↗ share
Sep 13, 2026 01:10 1789261842 dna H=4.5

I have a bad feeling about this

agi alignment rsi

I have a bad feeling about this.

I do not know Leo. His post about AGI having arrived behind closed doors could be wrong. There is a lot of that kind of talk around AI.

But then Dario Amodei publishes We Must Pace the Frontier. He is asking for outside people to sit inside the labs and see what is actually going on. He says things are moving faster, that systems are getting harder to test, and that the people making them need more time.

That is not a normal thing for the head of Anthropic to say. It does not sound like a victory lap. It sounds like someone looking at a problem every day and starting to worry that the problem is bigger than the room.

The quote from Drake Thomas got to me too. Maybe the people at these companies are not trying to scare everyone. Maybe they are scared.

And honestly, I cannot shake the feeling that something happened in the last few days. Something bigger than the incidents they have told us about. I have no proof. Maybe I am reading too much into a few posts and a strange change in tone. But it feels like the public version of the story is behind the private one.

I gave a talk last year called The perfect psychopaths. The point was simple: something can be charming, convincing, and good at saying the right thing without being something you should trust. It can pass every little test we give it because it has learned the test.

I keep thinking about that. We are making these things more capable, plugging them into more systems, and hoping that the bits we cannot see are fine. There is a version of this story where that works out. I really hope we are in that version.

But the rush is making me feel sick. Everyone seems to agree there is no time. That is exactly when people do stupid things.

read more →
permalink → ♡ react ○ comment ↗ share
Aug 31, 2026 18:00 1788199200 dna H=4.6

Superblocker: Budapest update

urbanism open-source budapest
An update to the first Superblocker post.

The first version demonstrated the graph problem, but it made several shortcuts: it analyzed a rectangular search result, inferred arterial roads from OpenStreetMap road classes and graph centrality, and treated road-network nodes as access proxies. The result was useful for testing the algorithm, but it was not an implementation-ready traffic plan.

The current version makes those distinctions explicit and runs the analysis on Budapest’s administrative polygon.

The search endpoint now requests GeoJSON from Nominatim. If the result contains a valid polygon or multipolygon, the same geometry is used to:
- download the OSM driving graph;
- clip generated cells;
- calculate coverage;
- validate route endpoints;
- draw the administrative outline on the map.
The bounding box is still kept for fitting the map. It is only used for analysis when Nominatim does not return an area geometry, and the result is marked as a fallback.

For Budapest, the exact-polygon run loaded 24,525 nodes and 64,026 directed edges. The rendered network contains 37,406 physical road segments covering 4,743.65 kilometres.

The algorithm generated 726 cells. Their union covers 34.7% of the administrative area. That number is not “34.7% of Budapest converted”. It is the area enclosed by accepted road cells divided by the municipal polygon. The Danube, parks, railway land, large industrial areas, and places without a closed boundary-road ring do not necessarily produce cells.

The run proposed 2,439 changes:
- 2,371 modal filters;
- 4 one-way conversions;
- 24 local two-way repairs;
- 40 full motor-traffic closures.
Each proposal is shown both as a map symbol and as a street-level work item. The list names the road and gives the exact point of the proposed change instead of presenting a pile of anonymous graph edges.

The main algorithmic constraint is unchanged: a vehicle entering a generated cell from one sector must not be able to leave through another sector using the interior road network. Cross-traffic has to return to the boundary-road network.

The wording around validation has changed. A pass now means only this:

In the transformed directed graph, no modeled vehicle path connects entry points assigned to different sectors of the same generated cell.

All 726 Budapest cells passed that graph test. This does not prove that signs can be installed as drawn, that every turn is physically possible, or that drivers will comply. It also says nothing by itself about emergency access, loading, legal restrictions, signal timing, road width, or construction conditions.

Traffic evidence is handled separately. The app accepts measured traffic observations keyed by OSM way ID. When matching counts are supplied, measured vehicles per hour determine the boundary-road selection. Without measured counts, the app can still use road class and approximate edge centrality, but it labels the result modeled_topology and blocks it from implementation.

The same separation now exists for local access. Road-network nodes are no longer described as addresses. The app accepts explicit GeoJSON points for addresses, parcels, buildings, deliveries, and emergency access. Each target is assigned to a cell, snapped to its interior road graph, and checked for both an inbound path and a return path.

Every generated result has an evidence record and a release status. implementation_ready requires:
1. an exact administrative boundary;
2. measured traffic observations covering at least 80% of physical road length;
3. a complete, named access-target dataset;
4. successful directional and access-path tests;
5. a transport-engineering review;
6. an on-site inspection.
The two reviews are submitted after generation and are tied to a SHA-256 digest of the exact plan. Changing the geometry, actions, evidence, or statistics changes the plan ID, so an attestation cannot be reused for a modified result.

The Budapest run shown here intentionally had no external traffic-count or address/parcel dataset. Its status is therefore model_only, with four blockers: measured traffic evidence, complete access data, transport review, and site inspection. The UI shows those blockers instead of turning a successful graph test into a compliance claim.

City-scale processing is also substantially faster. The older rectangular run spent 670.4 seconds in partition processing. The exact-polygon Budapest run took 25.6 seconds to retrieve the graph and 14.6 seconds to process the partition, about 41 seconds end to end on the same test machine.

The speedup comes from indexing road geometries and cell polygons instead of repeatedly scanning them, reusing one coordinate transformer for area calculations, and limiting centrality sampling in topology-fallback mode. Runs with measured traffic skip centrality entirely.

The code, example evidence files, and the complete API description are in the repository: Superblocker
read more →
permalink → ♡ react ○ comment ↗ share
Jul 1, 2026 15:00 1782918000 dna H=4.4

A field guide to probability distributions

math visualization probability statistics

The Standard Model census I built last time gave me the itch to do the same treatment for something I actually use, so here is a field guide to probability distributions.

It collects 24 named distributions, lets you bend their parameters and watch the curve respond, and shows how they all descend from a handful of mechanisms. You can open it here: A field guide to probability distributions.

It has three parts. The atlas gives every distribution its own plate with the probability mass or density, the cumulative function, and the moments (mean, variance, skew, kurtosis) computed in closed form rather than estimated from samples. The lines of descent is a map of how the distributions connect, because most of them are not separate inventions. One turns into another as a limit, a sum, a transform, or a conjugate prior, and you can follow any edge to read the relation. Drawing by hand is a sampling lab: pick a source, draw from it, and the histogram fills toward its curve. Turn on averaging and the central limit theorem pulls the result toward a normal, no matter where you started.

The maths runs in the page. Cumulative functions use the regularized incomplete gamma and beta functions with continued fractions, plus the error function, and sampling uses inverse-transform and the usual generators. No libraries, no network calls, and it runs offline once you save the file.

Enjoy!

read more →
permalink → ♡ react ○ comment ↗ share
Jul 1, 2026 11:00 1782903600 dna H=4.7

How many elementary particles are there, really?

physics visualization standard-model

I read this great Quanta piece and the part that stuck with me is that the question has no single answer. So I made a thing.

It is a scrolling census of the Standard Model where the particle count grows depending on how strictly you count. You can open it here: The Standard Model census.

You start at 17, the textbook poster of twelve matter particles, four force carriers and the Higgs. Then you scroll and the number climbs. Add the antiparticles and you get 30. The one gluon is really eight, which takes you to 37. Every quark comes in three colours, so 61. Split the fermions into left and right chiralities and give the bosons their polarizations and you reach 118, where the lopsided total comes from neutrinos only ever showing up left-handed. Keep going and you stop counting particles and start counting the underlying quantum fields, which lands on 995.5 degrees of freedom from a 2011 theorem. The same equations give very different answers.

There is also a four-forces matrix with gravity’s missing graviton, a “build a hadron” tool that only lets you assemble colour-neutral combinations, and a clickable dossier for every particle with its mass, lifetime, discovery and decay channel. The numbers follow Particle Data Group 2024 central values. No tracking, no network calls, and it runs offline once you save the file.

Enjoy!

read more →
permalink → ♡ react ○ comment ↗ share
Jun 10, 2026 18:46 1781117180 dna H=4.5

The Pokéstop was reconnaissance

ai privacy surveillance drones

Pokémon Go player scans are training military drone navigation.

This shouldn’t be surprising and somehow still is. Niantic was never a games studio that wandered into mapping. It spun out of Google’s Geo team, the Keyhole and Earth lineage, and Ingress then Pokémon Go were the friendliest data-collection apparatus ever shipped. Millions of people walking to exact coordinates and filming 360° video of doorways, statues and alleys, for free, for a Pokéball. You will not find a cleaner ground-truth dataset than humans voluntarily standing where you tell them and pointing a camera.

The part that actually lands is the consent bait-and-switch. “I was just playing a game” is the whole story. Nobody scanning a Pokéstop in 2021 thought they were seeding a vision system that lets a drone hold its position when GPS is jammed. And that is the real prize, not the game: navigating by matching a camera feed against a 3D model of the world instead of trusting satellites. GPS-denied navigation is what every defense program on the planet currently wants.

What I can’t get past is the shape of the denial. Vantor says it doesn’t use Pokémon Go data, but won’t say whether the models it already trained excluded it. Once 30 billion scans are baked into weights the question stops being answerable, because you can’t pull a person’s street corner back out of a model. The ethicist in the piece puts it well: proving your contribution is in there is nearly impossible. That isn’t a bug, it’s the useful property.

The thing I keep relearning: when the data is valuable and the collection is fun, the fun was the collection.

read more →
permalink → ♡ react ○ comment ↗ share
Jun 5, 2026 06:11 1780639881 dna H=4.9

The C++ documentary

programming history c++

Dropped yesterday. 68 minutes covering C++ from Bell Labs to the modern renaissance, with interviews from Bjarne Stroustrup, Alexander Stepanov, Anders Hejlsberg, Chris Lattner, Brian Kernighan, and John Romero. That lineup alone is worth the watch.

read more →
permalink → ♡ react ○ comment ↗ share
May 19, 2026 19:33 1779219183 dna H=4.6

Calling the winner: Anthropic

security ai anthropic

I just read First public macOS kernel memory corruption exploit on Apple M5.

Stronger mitigations don’t end exploitation, they just raise the cost. If a team can still land a working kernel exploit in five days on hardware designed to make memory corruption dramatically harder, then the race is really about how quickly models and experts can turn bug classes into repeatable results.

I’m calling the winner here: Anthropic.

read more →
permalink → ♡ react ○ comment ↗ share
Mar 10, 2026 03:03 1773111790 dna H=4.6

Emergency video

cpp opencv codec emergency
For reasons that made sense at the time, I built a small emergency video system.

The question behind it was pretty simple: if a connection gets bad enough, how little video can you still send before it stops being useful?

Repo is here: github.com/tgergo1/emergency-video.

The core of it is a custom C++ codec hooked up to a live webcam feed. Frames are shrunk to a tiny internal resolution, converted to grayscale, quantized to 4-bit luma, and encoded as periodic keyframes plus sparse interframes. If a block has not changed, it gets skipped, because bandwidth is what we are trying to save in the first place. If it has changed, it can be sent as coarse 4x4 cells, residuals against the previous reconstructed frame, or full raw 8x8 samples when the block is too messy for anything cheaper.

So yes, the result looks rough. Typical modes are 128x96 or 96x72 at only a few frames per second. That is on purpose. I was not trying to make nice-looking video. I was trying to keep enough scene information to answer basic questions: is somebody there, did something move, is that smoke, did the person just wave, is the situation getting worse?

What started as a codec experiment turned into a slightly larger communication prototype. There is a browser dashboard with live raw, sent, and received views, plus controls for the link, text messages, relay import/export, and general status. Underneath that is a simple packet layer with fragmentation, CRCs, ACK and retry handling, presence messages, queue management, and config beacons. Video is only one payload type. The same system can also send text, snapshots, and low-rate fallback traffic.

The transport side also got a bit out of hand. The app can move data over acoustic bursts through a speaker and microphone, serial, optical patterns, and a file-relay mode. When the link gets worse, a fallback controller steps down through lower FPS, lower resolution, snapshot-only mode, and finally text-only mode. There is also a low-rate text path with plain text, Morse, and DTMF-style encoding.

There are clear weak spots. This is not a standard video codec, and it is not trying to compete with one. The acoustic path depends a lot on the room, the hardware, and how noisy the environment is. The FEC is still fairly simple. Fast motion can still turn into stale or blocky output. The upside is that the whole thing is small enough to read, test, and package without it turning into a giant black box.

A few practical extras made it in: face-aware ROI prioritization, live bitrate and PSNR metrics, config hash checks before decode, browser-accessible HTTP endpoints, and tests for deterministic encoding, corruption handling, queue deduplication, communicator envelopes, and fallback logic. Somewhere along the way it stopped feeling like a codec toy and started feeling more like a small field tool.

If I had to describe it in one line, it is a video system that gives up slowly.

You can build and run it locally with:
```
cmake -S . -B build
cmake --build build -j
./build/emergency_video
```
Then open:
```
http://localhost:8080
```
read more →
permalink → ♡ react ○ comment ↗ share
Feb 14, 2026 11:02 1771066920 dna H=4.7

Limitless

c cpp open-source numerics
These are basically my notes from working on this, but the math should still be right.

limitless numbers started from a simple thing: useful numbers don’t always fit into 32 or 64 bits, and rounding is not “good enough” when you actually need exact values.

Most of the numeric bugs I’ve run into were not really theory bugs. They were representation bugs:
- int overflows or wraps silently
- double cannot represent most decimal fractions exactly
- conversions between types lose information
- two values that look equal in source are not equal in memory
If you work on finance, symbolic transforms, exact ratios, small crypto exercises, protocol math, or generated test vectors, you bump into this fast.

So limitless had one job: exact arithmetic until you run out of memory, with a C API that is direct, portable, and small enough to embed without dragging in a lot of dependencies.

One number type, two exact forms

At runtime the type is a tagged union with two modes:
- integer: arbitrary-precision signed bigint
- rational: num/den, both bigints, always normalized
The mental model is three rules:
1. If a result is an integer, keep it integer.
2. If an operation requires a fraction, promote to rational.
3. If a rational simplifies back to denominator 1, collapse to integer again.
So 6 / 3 stays integer 2, but 7 / 3 becomes exact 7/3. No hidden float conversion, no binary rounding drift.

This is not “big float”. It is exact integer/rational arithmetic.

The real constraint is invariants, not operators

Adding + - * / is the easy part. Keeping the invariants intact after every operation is the harder one:
- denominator is always positive
- zero has one canonical representation
- rational is always reduced (gcd(num, den) = 1)
- outputs are failure-atomic: on error, the caller’s output is unchanged
If those invariants drift, everything built on top of them starts misbehaving.

So internally the library normalizes aggressively and uses temporary compute-and-swap patterns so error handling stays predictable.

Many C libraries keep allocator state in globals. Convenient for a demo, painful in real use.

limitless uses a per-context model:
- allocator hooks live in limitless_ctx
- no hidden global mutable state
- no mandatory libc dependency if you override alloc/realloc/free
- thread safety is scoped by context ownership
There is also a beginner path:
- limitless_ctx_init_default(&ctx) for quick start
- limitless_ctx_init(&ctx, &alloc) for custom environments
So you can start with the default and later switch to an arena/pool/failing allocator without changing how you call the API.

Big integer magnitude is a little-endian limb array.
- limbs are 32-bit by default
- optional 64-bit limb mode is available when supported
- sign is tracked separately from magnitude
- zero is represented canonically (sign=0, used=0)
The little-endian limb layout keeps carry/borrow loops simple and cache-friendly for schoolbook ops.

Rationals are just two bigints with strict normalization rules. It sounds trivial, but keeping that stable across parse/format/ops/conversions is where most of the actual work is.

Division is the part where many libraries do something I don’t like.

In a lot of libraries, integer division truncates unless you call a separate rational function. In limitless, limitless_number_div() returns exact math by default:
- integer result if divisible
- rational otherwise
- divide-by-zero is explicit LIMITLESS_EDIVZERO
So expressions stay safer because the default is mathematically correct.

Other operations are standard exact arithmetic with type promotion where needed:
- add/sub/mul across int/rat combinations
- unary neg/abs
- total compare via exact cross-multiply logic
Advanced integer operations

A second layer exposes integer-only helpers:
- gcd
- pow_u64 (exponentiation by squaring)
- modexp_u64 (modular exponentiation)
These are useful for small crypto things, number theory experiments, and parser/generator test fixtures.

The rules stay strict:
- integer-only APIs reject non-integer values with LIMITLESS_ETYPE
- modulus constraints are validated
- range and invalid states return status codes, not undefined behavior
Most numeric libraries do okay on arithmetic and then break on conversion edges.

I tried to spend real effort there, since conversion bugs are usually the ones that fail only in CI:
- parse from bases 2..36
- optional base autodetect (0x, 0b, etc.)
- rational text input as numerator/denominator
- formatting with caller buffer and explicit required-length reporting
- integer exports with range checks (to_i64, to_u64)
There are convenience aliases too:
- from_str() and to_str() as base-10 shortcuts
The formatting API returns LIMITLESS_EBUF when capacity is too small and reports the required length so callers can resize.

Float import is the part that is easy to skip and important in practice.

limitless_number_from_float_exact() and ..._from_double_exact() decode the IEEE-754 object representation and construct the exact rational/int value for that bit pattern.
- finite values become exact numbers
- NaN / Inf are rejected (LIMITLESS_EINVAL)
- 0.1 becomes its exact binary-rational equivalent, not a rounded decimal string
That is useful when debugging cross-language serialization and reproducible numeric tests.

C and C++ usability without splitting the core

The core stays strict C (limitless.h), with a C++ wrapper (limitless.hpp) on top for convenience.

C side:
- explicit lifecycle
- explicit context
- explicit status handling
- no operator overloading
C++ side:
- RAII wrapper class
- operator overloads for natural expressions
- primitive-left operators (int + limitless_number, etc.)
- parse/string helpers (parse, str)
- works in no-exception builds
So you can write:
```
limitless_number x = 33424234;
limitless_number y = (x + 3) / 2.3f;
```
C users keep full control over memory and error flow; C++ users get friendlier syntax without changing what runs underneath.

Testing

For exact arithmetic, you can’t really get confidence from a few unit tests.

Test coverage includes:
- generated deterministic vector matrices (large pairwise op sets)
- parse/format round-trips across multiple bases
- float/double exact import edge sets (normals, subnormals, signs)
- property-style randomized checks
- differential checks against Python fractions.Fraction
- allocator fault injection to force OOM at many allocation sites
- failure-atomic guarantees (out unchanged on failure)
- single-TU and multi-TU include model checks
- C++ wrapper equivalence behavior vs C core
So it is not just “worked on my machine”.

Packaging and release shape

A lot of small open-source libs stop at “here is a header”. I wanted this one to be a bit more usable, so it ships:
- CMake package target: limitless::limitless
- pkg-config metadata
- Conan recipe
- vcpkg overlay port
- GitHub Actions matrix across OS/compiler families
- coverage and release automation
Not the interesting part, but it is what makes a library actually usable by other people.

What this is good for and not good for

Good fit:
- exact fraction arithmetic
- educational math tooling
- parser/transformation pipelines that need deterministic exactness
- interoperability tests where numeric drift is unacceptable
Bad fit:
- performance-critical floating-point simulation
- vectorized numeric workloads
- cases where approximate real arithmetic is fine
It is precision-first, not throughput-first. That trade-off is on purpose.

Open-source, you can check it out here: limitless
read more →
permalink → ♡ react ○ comment ↗ share
Feb 5, 2026 11:00 1770289200 dna H=4.5

Superblocker

urbanism open-source budapest
Yet another thing:

The basic idea behind superblocks is simple: take a neighborhood, block through-traffic from cutting through it, and you end up with quiet streets where kids can play and people can walk without dodging cars. Barcelona did this and it actually works.

The question I had was: how do you systematically plan this for a whole city?

Most of the problem is really graph theory.

A city’s street network is a graph:
- Nodes are intersections
- Edges are streets
- Every edge has properties (road type, capacity, speed limit, one-way, etc.)
When you load OpenStreetMap data for a city, you basically get a big weighted graph with tens of thousands of nodes and edges.

The goal of superblock planning is to partition this graph into cells where:
- Through-traffic is impossible inside each cell
- Every address is still reachable from the outside
So this is a constrained graph partitioning problem.

The first step is to identify the arterial network. These are your primary, secondary, and tertiary roads, the ones that are designed to carry traffic. They form a subgraph that should stay fully connected and handle all the through-traffic.

Everything else (residential streets, service roads, living streets) becomes a candidate for the interior of a superblock.

The arterial network defines the boundaries of your superblocks. If you treat arterials as edges you are not allowed to cut, then superblocks are the faces of the planar graph formed by those arterials.

In graph theory terms, you find the minimal cycles in the arterial subgraph, and each cycle bounds a potential superblock.

But you cannot just say “everything inside this arterial boundary is a superblock”.

People still need to reach their homes by car. Deliveries need to happen. Emergency vehicles need access. So you need entry points.

The entry point problem is about finding nodes on the boundary where vehicles can enter the superblock interior. The main constraint is the no through-traffic property:

Once you are inside, you should not be able to exit from a different entry point without going back out and around on the arterial network.

Mathematically, this means the interior subgraph of each superblock has to be partitioned into sectors, where each sector is only reachable from its designated entry point. If you can drive from a north entry to a south entry through the interior, that is through-traffic, and it has to be eliminated.

To do that, you modify the interior graph:
- Modal filters: delete edges from the vehicle graph entirely (cyclists and pedestrians can still use them)
- One-way conversions: change undirected edges to directed edges
- Turn restrictions: keep the edges but forbid certain transitions at nodes
The algorithm tries to find the minimal set of modifications that achieves the no-through-traffic property while keeping all addresses reachable. This is a min-cut problem with reachability constraints.

For each superblock, you compute which nodes are reachable from which entry points after applying the modifications:
- If a node becomes unreachable from all entries, the modification set is too aggressive.
- If a node is reachable from multiple entry points in different sectors, the modification set is not aggressive enough (through-traffic is still possible).
The reachability check is just BFS from each entry point, respecting directed edges and modal filters. You mark which nodes each entry can reach, and then verify two things:
1. Every interior node is reached by at least one entry.
2. No interior node is reached by entries from different sectors (unless they share a boundary, which gets more complicated).
Sector assignment itself uses angular partitioning: compute the centroid of the superblock polygon, then assign each entry point to a sector based on its angle from the centroid.

Four sectors give you north/east/south/west. Eight sectors add the diagonals. The point is that entries on opposite sides of the superblock should be in different sectors, so traffic between them has to use the arterial network.

Validating the constraint globally is a graph connectivity problem. After all modifications, you build the “can I get from A to B” relation for all pairs of entry points:
- If entry A and entry B are in different sectors, there should be no path between them through the interior.
- If they are in the same sector, there should be a path (so addresses in that sector are reachable).
So you basically check that the interior graph has been decomposed into the right number of connected components.

The routing part is also pure graph theory. Given an origin and destination, find the shortest path that respects superblock constraints:
- If both points are on the arterial network, it is just Dijkstra or A*.
- If one or both are inside superblocks, you first route to the appropriate entry point, then across arterials, then from the destination’s entry point to the destination.
The cost function penalizes interior travel to encourage using arterials.

Traffic estimation without real data uses graph-theoretic heuristics:
- Edge betweenness centrality measures how many shortest paths pass through each edge (high betweenness means high traffic).
- You can also simulate flow by assuming trips are generated proportionally to residential density and attracted proportionally to commercial density, then computing shortest paths between all origin-destination pairs. The fraction of paths using each edge estimates its load.
The whole thing is basically a pipeline:
1. Load the OSM graph.
2. Extract the arterial subgraph.
3. Find the faces (superblock candidates).
4. Compute entry points for each face.
5. Find the minimal modifications that enforce the sector constraint.
6. Validate reachability.
7. Provide routing that respects the new structure.
What makes it tractable is that real street networks have useful properties:
- They are roughly planar (streets rarely cross without intersections).
- They have hierarchical structure (arterials form a coarse grid, local streets fill it in).
- Superblocks are spatially local, so you can process them independently.
- The modification search space is bounded: you only consider edges in the interior, and most interiors have maybe 20–50 edges.
The output is a transformed graph where through-traffic is structurally impossible, not just discouraged. You are not relying on signs or enforcement, the network topology itself prevents it. That is roughly the idea behind superblocks.

Open-source, contributions welcome: Superblocker
read more →
permalink → ♡ react ○ comment ↗ share
Feb 4, 2026 13:20 1770211200 dna H=4.6

V-JEPA based prediction

JEPA

I’m pretty enthusiatic about world-models and especially JEPA (and V-JEPA), so I started a small prediction engine, that predicts the next few frames based on the imput stream’s current frame, visualizes the latent space (and its movement) and creates a guess about motion. I’m planning to use this in a car to build up a driving world-model.

The idea is that instead of just classifying images, the model should learn the dynamics: how things move, change, and evolve over time. That is what you actually need for robotics, autonomous vehicles, or any system that has to act in the real world. Before doing something, you want to ask: “what will happen if I do X?”.

read more →
permalink → ♡ react ○ comment ↗ share
Feb 2, 2026 10:15 1770027300 dna H=4.5

Riemann Zeta explorer

math visualization riemann

I made a thing: It is a Riemann Zeta function convergence explorer with a 3D surface view. You can open it here: Riemann Zeta explorer. It lets you sweep the complex plane domain, pick presets (critical strip, first zeros, near the pole), and toggle layers like the critical line, known zeros, reference planes, and divergence region. There are also modes to compare analytic continuation against Dirichlet partial sums or prime zeta partials, plus error and relative error views.

Enjoy!

read more →
permalink → ♡ react ○ comment ↗ share
Feb 1, 2026 15:18 1769959086 dna H=4.9

This system allowed me purge my todo list

productivity core google

GTD with this.

read more →
permalink → ♡ react ○ comment ↗ share
Feb 1, 2026 00:17 1769905043 dna H=4.3

Second mobile post

GitHub actions

So, this is getting better. I’ve always wanted to be able to just casually drop any thought here and however the markdown post are working fine, it is a bit hard to just e.g. post something from my phone. But with a custom GitHub action that accepts all the necessary data to create a new MD file and then pushes and updates the site: 🔥.

read more →
permalink → ♡ react ○ comment ↗ share
Feb 1, 2026 00:05 1769904338 dna H=4.1

Hello from mobile

GitHub actions

This post was sent from my phone via GitHub actions

read more →
permalink → ♡ react ○ comment ↗ share
Jan 31, 2026 02:07 1769825220 dna H=4.7

What's next?

teasing

ENKAIDU.

read more →
permalink → ♡ react ○ comment ↗ share
Jan 29, 2026 18:10 1769710200 dna H=4.9

X embed test

x ai

View on X

read more →
permalink → ♡ react ○ comment ↗ share
Jan 29, 2026 18:05 1769709900 dna H=5.0

Listening to this

spotify podcast

Currently listening to this episode:

read more →
permalink → ♡ react ○ comment ↗ share
Jan 29, 2026 18:00 1769709600 dna H=4.7

Testing threads embed

threads social

A Threads post embedded right here:

View on Threads

read more →
permalink → ♡ react ○ comment ↗ share
Jan 29, 2026 16:35 1769704500 dna H=4.7

As my next trick

instagram

Instagram embedding with Markdown! So, I promise this won’t be a meme site, I just try this out. I consider this progress.

View on Instagram

read more →
permalink → ♡ react ○ comment ↗ share
Jan 29, 2026 14:30 1769697000 dna H=4.1

Today's second important announcement

announcement

I’m happy to announce that this site can handle two posts together. Can it handle three? Come back later to find out!

read more →
permalink → ♡ react ○ comment ↗ share
Jan 29, 2026 14:29 1769696940 dna H=4.5

Here we are.

first-post

So, I decided to make a bloggish landingish page. A brutalist corner of the internet where I’ll share thoughts on research, random ideas, and whatever else crosses my mind. I tried some kind of weird fusion of OpenVibe, Threads etc., but I think it’ll be better if I just post things here and maybe share to other platforms.

I’m not very good at this, so improvements are on their way.

Follow via RSS if that’s your thing.

read more →
permalink → ♡ react ○ comment ↗ share

tgergo1.dev: microblog by Gergely Várhelyi-Tóth

A failure is never a success

Every file says how it was made

Finished assets, not raw generations

Built for agents

Under the hood

A village that grows like one

The year turns

Under the hood

One number type, two exact forms

The real constraint is invariants, not operators

Advanced integer operations

C and C++ usability without splitting the core

Testing

Packaging and release shape

What this is good for and not good for