daymare.net

DAYGPT

2026-06-10T21:47:34.772763855+00:00

A public Q&A board where anyone can ask a question, and answers are posted here for everyone to see. You might ask why 'GPT' when I'm the one answering the questions, simple!

It's because I'm better than AI

This was a super silly project, oh my god I loved it so much. I've had a sayout link on my twitter account for a good while now, but I thought now that I've got this demo system why not have my own server?

I know you probably wouldn't guess this but this was my first time experimenting with servers. In fact, to get this to work I setup my home mac mini as a cloudflare server tunnel. So put your name in or stay anonymous, but either way ask something! That's the only way I'll be able to get ROI on the time I spent on this.

Oh also, your messages are NOT visible to anyone else but you until they get answered. This is to prevent internet people being internet people and ruining everything. But I promise I'll get to it!

If you want to support me, I have a ko-fi and also a discord server where you can ask me more questions.

Tech

I'm not really a huge web fan, but I thought it'd have been absurd to spin up a whole WASM app for a silly project like this so I used Javascript.

Not any of the fancy stuff though, this is just a plain ol' Javascript and HTML app.

I've also integrated it with DiceBear so I could generate cool profile pictures for people based on their usernames.

I also have a cool little admin dashboard, don't get too happy about it though I have a very secure 256bit key. I'm gonna regret saying this aren't I..

While writing that I started wondering how many ways people could abuse this and I noticed I didn't have a length limit. Well, I do now! It's 4096 characters, though the client side doesn't reflect it right now so... let's hope no one talks too long

Privacy and data stuff

I don't really need this but just to be transparent:

your username is not unique, it cannot be linked to you. Anyone can have any username. Its mostly there to create conversation and a silly avatar.
I store the messages you send, alongside the username you gave at that time.

RAVIOLI: Tower Defense

2026-06-09T14:48:47.251195650+00:00

A factory building tower defense game. Oh boy where do I even start. This has been a long project that has gone through many, many iterations.

The core idea of making a factory game has been with me for a good while now and I've been working on it for about a year at this point. But ravioli itself, I've been working on for the past 6 months.

Initially, this was meant to be a 3D game, with a voxel engine. And while the tech of a voxel engine was evidently very interesting to me (I mean, I've written not one, but two posts about it. The latter of which was an in-depth guide on how to make one, even if not optimised) I wasn't able to make the gameplay feel enjoyable. Primarily because of the 3D grid-based nature of it combined with me not being able to think outside of the box (heh).

But I think this 2D version we have now works great. I've been working on it and really enjoying it a ton. More about the tech behind it after you check it out.

The Tech

If you've ever read my previous blog posts, you probably already know I'm very comfortable not using a game engine. Ergo, I didn't use one for ravioli either. The game is completely written in Rust, using wgpu for graphics and winit for window management.

Other than that, the rest is pretty standard.

I think I should address a question I get surprisingly a lot for someone who has 30 people in their discord: why not use a Rust game engine.

Or, more specifically, why not use bevy? For the unacquainted: bevy is, in their own words, "A refreshingly simple data-driven game engine built in Rust".

The reason I didn't use bevy is because I don't think an ECS is the correct driver for my game. At its core, ravioli is a very simple game. You have structures like assemblers, belts, turrets, and you have entities like bullets, enemies, explosives.

Obviously there are different ways these things interact with each other, for example while all other structures can be evaluated in pretty much any order belts need to be evaluated in a certain order to ensure items flow correctly. Or Martyr nodes need special handling so that you can form health networks without them destroying each other.

But nevertheless, none of these would benefit from an ECS. They're entities with systems yes, but I have no need for components and what little need I might have is trivially solvable by using tagged unions.

You could argue it'd make the game faster, more performant. And you might be right, it would maybe allow you to get 50,000 entities at 60fps instead of 10,000. A 5x difference! It might make the code a bit more complicated but come on, a FIVE TIMES DIFFERENCE IN PERFORMANCE!

But also, in ravioli maps are small and contained. It's not open world with an infinitely vast horizon.

But also, if it was open-world like for example factorio, I wouldn't want a generic ECS like bevy either. I'd hand-roll my own system that's specialised for my usecase.

I think it's amazing that we have engines that people can just pick up and use, I mean for a good portion of my life I've used raylib for everything because I didn't want to learn OpenGL. But I don't think bevy is the right choice for me.

If you're interested, I recommend reading this by LogLog Games. It's quite a long read about Rust and gamedev. If you have the time, definitely read all of it it, but if you only have 5 minutes, at least read the section about ECS.

Conclusion

ravioli is currently in development, so I'd absolutely love to hear what you think. So please join us in my discord server and if you want to support the development monetarily, I have a ko-fi page!

Thank you for reading, and I hope you enjoyed the game!

One of Those Bugs

2025-12-07T08:03:27.243156829+00:00

You know how every project has one of those bugs that make you question whether or not it's even worth it to continue?

Yeah, me too. From recent memory, not including today's, my RISC-V Emulator project got abandoned because I couldn't figure out a bug that was happening with virtual memory. But I was working on margarine this week (read more here) and I'm not going to abandon margarine again. It's the longest running toxic relationship in my life.

I hear you, it's weird to write a whole post about a single bug. But it's my blog page and I've survived the gauntlet to Olympus and I'm going to tell the tale damn it.

Let me set the scene, I'll try not to yap too much.

It was the start of this week, Advent of Code had just started¹, so as any good compiler-dev does I went ahead and started solving it day-to-day in margarine. Day 1 went smooth, I had to add a bunch of features to margarine such as tuple destructuring, multiple standard library functions and a LOT of bug fixes that were relatively easy to do. And then, day 2 arrived.

Part 1 went relatively smoothly, too smoothly. I had the answer 40055209690.

I moved onto part 2. I wrote it, compiled it to see if there were any compilation errors. See, the thing with margarine is that right now I don't have a separate build command, I just do run and it compiles it & runs. So when I compiled it to check for errors inevitably the part 1 code also ran.

There were no errors. But umm, why did it print out 47353585426?

And this is where my journey started. For some reason, adding new code broke existing code. I do mean adding new code, not executing new code because the part 2 solution wasn't even in the main path yet, it was just inside the file.

Okay, let's see. The program is very closure & generic heavy. So I thought, alright, the problem is probably with the way I handle monomorphization which led me to go ahead and disable the function cache. Before, when I saw foo::<int>() I checked a HashMap to see if that function had already been generated. After disabling the function cache I was just creating a new function instead of reusing a newly generated one. That fixed it! But uhh, why?

I went to investigate, because I can't just leave the function cache off! That'd generate way too big code files for my singular user!

I have a custom hash function for symbols in margarine. Because margarine has a slightly more complicated type inference system than the simplest of type systems a symbol can be a type variable. We can't just hash a type variable directly, otherwise two generics that resolve to the same type would get different hashes, and the cache would explode.

Which meant that the function cache HashMap is a HashMap of TypeHash and Function. Which means that it can no longer protect us from hash collisions. Aha! The problem is that we're getting a hash collision! That's a reasonable conclusion, 18 quintillion possible numbers and just my luck is a hash collision.

I added a simple check to the get_func function. Well, that's not the problem. Okay, how about closures? I mean the code is very closure heavy so if functions in general aren't the problem maybe closures are. Because when I disabled the function cache I also had to disable it for closures as well!

Aha! (chatgpt ahh emotes bro) Closures are only hashed based on the closures type + expression id. Maybe it's not accounting for generics and captures, though if the expression id is unique that should account for captures as well. Regardless, doesn't hurt to try!

I went ahead and added everything a closure could want to its hash but yet the problem was still there. Then I had the thought, maybe the closure isn't getting uniquely hashed because everything is still in generics! The issue is in how I've implemented generics! That's why turning off the function cache fixed the problem, it removed generics from the equation!.

So the way I've implemented generics is quite possibly the dumbest way ever. I just register them as empty structs in the type table when type checking the function and when it comes to code generation I just create a name to type mapping. Maybe somewhere it's not mapping properly!

Look, I would not do it this way if I were making it now but margarine has been going on and off for 2 years or so, it's basically legacy code for me.

I went back and added a custom Generic variant to container types, so now I still register them as symbols to the type table but at least I know that they are generics and not just empty structs. Then, I went to the get_func function and added an assertion to make sure that the requested function is a fully resolved type.

Yess! There were multiple places where this assertion failed. Field accesses, identifiers, even closures! I fixed those cases, resolved the generics completely and it compiled fully!

Now, margarine's runtime is very slow right now (200-300MIPS), especially for the task day 2 was asking of me. So it took a good 30 seconds to run the entire test each time I wanted to see if it worked. I was counting for 4 garbage collection messages, because the garbage collection still had the debug prints for "garbage collected in 5ms".

The tension was high is what I'm saying.

garbage collected in 4.7ms
garbage collected in 3.5ms
garbage collected in 5.2ms
garbage collected in 4.1ms

...
...

47353585426

..FFFFFU- ntastic! The problem still exists.

Okay, well that whole refactor didn't fix the problem. It also didn't make it worse. Though, I can't help but wonder how my code was even running before that refactor. Like, I wasn't even resolving generics and it was working just fine. Anyways, not the time to celebrate when my program is still broken.

Wait, let me check the output of the codegen. Waiiiittt, the codegen is IDENTICAL except for the extra batch of functions.

Oh god I've been looking at the wrong thing this whole time?

So the problem is in the runtime. Okay well, I could just output every single instruction and then figure out where the divergence happens.

Except, when I tried that the output file was 14GBs and it took 15 minutes to run. Look, VSCode crashed while trying to open that file at 3GBs, NVIM couldn't even handle 2, and all that is before I even diffed it in the first place.

I really doubt diffing it is going to work.

This threw me for a bit of a loop. I tried running it on smaller examples but the bug never happened in them. I had to find where the difference was in a 14GB log file. Except, I don't really need detailed logs on every part of the program, do I? I just need details around where the difference started.

Here's an idea, what if we hash 100k instructions and print that. That'd cut down the file size by a lot! Then we can just figure out where the first difference is and add logs around there until we find the instruction that was causing the problem!

Let me tell you, that worked amazingly! The problematic instruction was somewhere around 37 million instructions.

For some reason, that EqObj instruction was returning false.

Ah! The split function was failing, probably. Wait no the split function is fine. What is going on here?

From this point, I don't know how to explain it much but somewhere along the way I thought "alright, let's reduce variance and just give it a lot of memory to work with so the GC doesn't run".

Oh.. So the problem is the GC? Yep!

But what exactly is the problem? No idea, that's a mystery I've yet to solve. For now, I've just disabled the GC until I figure out how to fix it. From my perspective, the GC looks perfectly fine, and the code is extremely simple.

One day, I'll fix the GC. Today, however, is not that day.

If you have any theories, feel free to share them on my discord.

It really goes to show how hard it is to track down the source of a bug sometimes. I mean that whole function cache thing was a giant red herring!

Sometimes while trying to fix a bug you fix 5 others before fixing the actual bug that got you started. Makes you wonder how your code even ran properly in the first place, huh?

BTW, You can check out margarine here and if you enjoyed this post if you could spare a cup of coffee, it would be delightful.

¹: It's only 12 days now 🥀

But why is AI bad?

2025-11-30T09:24:53.775846+00:00

Lately, I've been trying to understand our collective discomfort with AI generated content, and why we've drawn the line where it is. Now, now, calm down, put the pitchforks down.

Hear me out:

My main audience is programmers so I'll start there.
Don't worry, artists, I'll get to you, too.

Say a programmer makes a tool to solve his problem, maybe to manage his config files.

He goes: hmm, if this is useful to me, maybe someone else on the other side of the world in a decade or two might find it useful too! And puts it on GitHub.

But he's been there: finding a really cool GitHub tool with zero documentation.

That's just how it goes. You make something for you, then toss it on GitHub because well why not? But you're not gonna spend a day documenting the tool you made on a weekend, are you?

So he thinks to himself, you know? Maybe not a day, but I can spare a few hours, what if I use this new AI thing to write the majority of the documentation and then just audit it. That way, if someone finds it they at least have something.

That sounds fine, right?
But I can assure you, when he's sharing his tool he's going to get flamed for using AI to generate the docs.

From the outside? It's just AI slop.
It looks like he used it to avoid work he would've done otherwise.
But we rarely consider the possibility of "what if it wasn't a shortcut"?
What if the AI made him spend more time because without it, the docs would have never existed in the first place?

So I want to ask you, dear reader: would it really have been better if the tool had no documentation at all?

"Wait, you're saying AI is good?"
Yes- No? AI used to create something is better than nothing.

Let's look at another discipline, art.

Now I'm not an artist so excuse my French here but let's take a painter who wants to explore new art styles, but can't, due to illness or injury.

How harmful is it for the painter to use AI to create?
Is it harmful that the AI was generated on content the artists didn't consent to? Of course! But how much of it is the painter's fault?

You see the pattern, yeah?
We have these incredible tools but we're not letting ordinary people use them.
We're encouraging dreams to stay dreams.

What if someone uses AI to learn the guitar? Like, using it to get feedback.
Well yeah! That person could go to a guitar teacher instead!

When we say that, aren't we gatekeeping learning to those who have the money to afford it?

"No that's not what I meant!"
No I know. When you decided you disliked AI, you meant corporate bullshit.

Firing artists, replacing programmers and voice actors, cutting corners. Selling AI generated slop at full price.

Creating bullshit "Top 10" lists, expensive courses and books that are obviously auto-generated.

Thinking AI replaces human talent.

I agree, that's bad.

But that's not me,
That's not you,
That's not them.

So why are we the ones catching strays?

People's anger is at the indie dev using GPT to make their dream game, but not at the startup selling trash to VCs at scale.

Because they're easier to reach than the people we're actually mad at. And so we end up blaming people trying to build, learn, and share while letting the ones ruining industries go untouched.

I'm not saying you're doing this. I don't know you.
But there is a dangerous pattern and we need to be careful about what incentives we're indirectly promoting.

Because right now? You can't use AI, I'll ruin your reputation and drain your passion. Unless you're the CEO in which case I'm still mad at you but I can't do anything about it so I'll go be angry at another indie.

It's annoying. We have this purism mentality that is harming everyone.

Look, I'm only a single person so I'm sure to some of you I've missed the whole point. Regardless, I'd love to hear other people's perspectives so if you want to discuss this you can leave your torches here too and find me over at my discord server.

psst, can you consider tipping me on ko-fi? thank you!

No, LLVM can't fix your code

2025-11-23T14:21:13.916512177+00:00

Y'all mind if I rant a bit first, promise I'll talk about a few optimizations that got my RISC-V emulator to run at 550 million instructions per second purely interpreted.

This is sort of a follow-up to Speedrunning a CPU. But before I talk about what I did to make it run that fast

Let me set the scene, alright.

2023, I'm deep in the compiler-development scene (see: Four Years, Five Failures, One Compiler) and this is about the time where I discovered arenas and StringMaps.

An Arena, at its core, is a big vector of bytes. You can put any data you want in there. If I wanted to store a Foo, I'd just write it into the buffer and bump a pointer by sizeof(Foo). Basically a very fast way to allocate data (like malloc), but without the ability to free anything individually afterwards.

This is useful in compilers since you have a lot of data to allocate and more often than not the drawback doesn't matter since you won't be releasing memory in individual bits but in phases (think lexing phase, parsing phase, semantic analysis phase, etc.).

Then there's the StringMap, which is a HashMap + a vector of strings. You have a HashMap of String to an index into a vector, and then a bunch of Strings.

With this you can convert all strings in the program (identifiers, actual strings, etc.) to an integer index which not only has a smaller payload but also comes with constant time comparison. (think it's actually called string interning?)

These kinds of data-structure decisions are what I'd call macro optimizations. The ones where you really can't expect LLVM to help you with, but of course that doesn't stop people from believing LLVM will.

Anyways back to the rant, I was having a conversation with someone who was making their own programming language as well. He was trying to improve his compilers performance but he was tunnel-visioned on micro-optimizations.

Look I love to give my opinion on things without being asked as much as the next guy, but this time I was asked. And considering I'd just spent weeks squeezing out huge gains from StringMaps alone, I naturally suggested he give it a try. That's when he hit me with:

LLVM can already handle those with mem2reg and stuff, so why would I complicate my code?

I can't make a deep breath sound in a blog post but just imagine one here. The fact that I still remember this quote probably says a lot about how deeply it shook me. Not to mention that this was coming from someone making compilers, someone who presumably knows more about what a compiler backend can do than the average dev.

Just to be clear: no, LLVM can't and won't magically turn the thousands of generic containers and redundant string copies into a cache-friendly arena-backed interning engine.

But, while that is a conversation that stuck with me, I think (I hope) that most of us know that LLVM can't do these macro-optimizations that drastically change the data layout of the program.

There is, however, a category of optimizations I'd expect LLVM to be able to do

Micro-optimizations

Let's jump to the end of last week, optimizing the RISC-V emulator portion of the story.

Micro-optimizations include the aforementioned mem2reg, loop unrolling, constant folding (converting stuff like 3 * 4 to 12 at compile time), etc. the stuff that is very localized and would be tedious to do by hand. Not much reason to talk about the stuff that LLVM already handles so let's zoom in on one micro-optimization that needed my help.

But before that I'd like to give an honourable mention to likely/unlikely path hints.

These fellas gave me about 100MIPS~ of performance in the emulator and solve a particular kind of information problem: LLVM doesn't know what your data is, so it needs to assume all branches are equally likely to be taken if it can't infer otherwise.

This is a problem because it messes with the branch predictor and pollutes the instruction cache. But if you know something about your data, like that time_elapsed > 5s almost never happens, you can tell LLVM to put that in the 'cold' section so the CPU doesn't even think about it. Which makes the hot path possibly way faster, and also makes the cold path way slower but that's a tradeoff we can choose to make.

Now let's actually talk about the optimization that gave me more than 75MIPS.

No, it's not removing bounds checks. I think I still have those in the emulator, those really matter less than you'd think (hey cold paths!).

It's actually just deleting 5 letters.

self.cycle += 1;

into

cycle += 1;

uh, so what did that change do exactly? Well I'm glad you asked, me from 10 seconds ago! It moved the cycle from stack memory into a CPU register.

Okay well, technically the code change was a bit more than that because LLVM can move things in memory into a register (hey mem2reg is back!).

That is as long as the variable isn't passed mutably into a non-inlined function. Otherwise LLVM would have to assume it could be modified¹ and write it into memory before calling the function and at that point oftentimes LLVM just prefers not to put it into a register.

In this context, the cycle counter is incremented every single instruction and isn't really passed into a lot of functions so I was really expecting this change to do basically nothing. Especially considering I had to put something like:

if unlikely(cycle % 128 == 0) {
    self.cycle = cycle;
}

in the main loop.

The end

Well, that's it. The moral of the story is that LLVM isn't sentient yet. Maybe when we solve the halting problem.

But until then, hope to see you in my discord server.

If you enjoyed this, considering dropping me a coffee.

Either way, I'll be here as usual next Sunday.

¹: Yes, LLVM does fancy things like function specialization, inline heuristics, and other stuff. This is still a gross oversimplification, but I have no interest in doing a deep dive into all of that nor am I in any way qualified to.

Speedrunning a CPU: RISC-V in a Week

2025-11-16T00:07:52.323736212+00:00

I made a RISC-V Emulator that runs at 550 million instructions per second from scratch in one week. Here's how it went.

So, here's the thing. After the Voxel Engine in a Weekend project, I was looking for a new challenge. That's when I thought, huh, why not make an OS? And a compiler running in that OS, and also a browser, a neovim clone inside that OS, and while we're at it GTA 6 as well.

But of course I couldn't just learn to make an OS, nah that'd be too easy. And I quote:

Why stop at an OS, why not make your own CPU that runs your own OS with your own language that compiles to it.
08/11/2025

I had to start from the CPU itself, otherwise how could I be proud of it. And I also had to do it fast, considering for this entire project (the OS, browser, compiler, neovim clone, GTA 6) I allocated myself a generous singular year. It was set, I was going to speedrun making a CPU, and I was going to use RISC-V.

Step 1: Say you'll make an assembler too!

Okay I hear you, I just said "gotta go fast" and now am considering making an assembler for seemingly no reason. In my defence, I had not a single clue where to start, but I have made plenty of programming languages so I thought: okay, if we're going to do this I might as well start with an assembler, since it'll be a nice easy step to smooth out the curve and get me used to the binary format of RISC-V.

In theory, an assembler is as simple as it gets. You have really simple syntax, maybe a few shapes of instructions, basically no semantic analysis, and a trivial 1:1 code generation phase. In practice, however, GOOD assemblers are filled with macros, pseudoinstructions, constant folding, and probably so much more that I can't think of off the top of my head.

Are any of these really hard? Not really. But all of them require a lot more knowledge in the target instruction set than I had at the start of this week. Pseudoinstructions aren't officially documented... what the hell is a macro... constant folding who? You can probably guess that my hope of writing an assembler vanished VERY quickly, and all of that before I even got to the codegen part of the assembler. You know, the part that's actually useful to me making an emulator?

I could've made a toy assembler, but would I have used it? Absolutely not. This thing is hard enough already I don't need one more thing to debug. So I made the very difficult and heart breaking call to not make an assembler.

Step 2: Oh it's only 200 pages-

Now, time for the emulator. I wanted to, I needed to keep this emulator as simple as possible so I could complete it in this week. So I decided, no virtual memory, no fancy extensions, no jit, nothing fancy. And then it was Sunday morning.

I opened up my computer with the hopes to get the emulator started. See, the first thing I do with any interpreter I make is to run the recursive-Fibonacci algorithm. It's a nice little stress test that is very easy to run and gets the dopamine flowing you know? So I went to the RISC-V site to check out the instruction set.

There were 2 specs. Volume 1 for unprivileged architecture, and Volume 2 for privileged. Since my goal was to make an OS and not to compile to a RISC-V user platform I thought: okay, I just need Volume 2. I opened it up and it had about 221 pages. Okay that's a lot of pages. Hell, that's 6 pages of just table of contents.

But it's managable, I could skim through it in a day or so and then reference it back or something. So I got looking. Huh. I can't see where the instructions are.

Here's the thing, dear reader. You might've noticed that the books are titled Volume 1 & 2, and while I didn't think they actually meant it in that way they absolutely did. The instructions were on Volume 1 as well.

Would you like to guess how long Volume 1 is?
About as long as Volume 2? Yeah that's about what I'd expect too,

NOT 727 PAGES.

I ain't reading all that. If you're curious that's 19 pages of table of contents.

Granted the spec is very well structured and looking back all I would've had to check out was maybe about 20-30 pages filled with diagrams. But '727 pages' was enough to make me close the tab and look for other more concise sheets. And that's when I found it. My saviour, Writing a RISC-V Emulator in Rust. When I saw this I went

Omg, I don't need to learn anything let's go!

..that is, until I clicked on the link. Here, I'll show you the table of contents of it at the time of writing:

Writing a RISC-V Emulator in Rust
   1. Hardware Components
      1.1. CPU with Two Instructions
      1.2. Memory and System Bus
      1.3. Control and Status Registers
   2. Instruction Set
      2.1. RV64I Base Integer Instruction Set

And, that's it. I'm not trying to bash on the creator of it I'm sure it's either an unfinished or even an abandoned passion project, but when I saw this the timing was so unfortunate it became funny. For those curious, that's about 0.1 pages of table of contents.

BUT THEN IT APPEARED!

My actual saviour,
the RISC-V Instruction Set Specifications by some random github person.

It was pretty, it was useful, it sometimes had typoes and mistakes, but most importantly, it had whitespace so it didn't look scary.

Step 3: ..make the thing already?

It was still Sunday. I got some very basic RISC-V code working.

    .section .text
    .globl _start
_start:
    li   a0, 42
    li   a1, 99
    add  a2, a0, a1
1:  j   1b                # infinite loop

can you guess what it does? Probably not, it's too advanced.

But now that I had this very simple snippet working the momentum curve was slowly tilting in my favour.

By the end of Sunday I had 13 instructions ready. And fast forward a few days I had the entirety of RISCV64I implemented. Which of course surfaced a new kind of problem. The hardest, least motivating part of writing an emulator like this is that you really have no idea if your implementation is correct. Sure yeah your programs might be working but you don't know the edge-cases, and when a program doesn't work like you expected good luck trying to debug it.

When I brought this point up to one of my friends he linked me the RISC-V Test Suite, which I promptly ignored in favour of compiling some Rust code and running it on my emulator.

..damn, all that set up for nothing.

Okay, to compile Rust to RISC-V, Rust provides a bunch of pre-made targets. But you see, RISC-V at it's core is a very simple instruction set with 47 instructions and it provides optional extensions like multiplcation, floating-point numbers, atomics, etc. And not implementing these optional extensions is really not an option with Rust's premade targets.

So I had to make my own custom Rust target. Which sounds interesting but was mostly done by my friend and when I asked him how he did it his response was "I asked ChatGPT and copy pasted the errors until it worked". Which, fair enough.

Of course, the first thing I compiled with Rust was

fn fib(n: usize) -> usize {
    if n <= 1 { n }
    else { fib(n-1) + fib(n-2) }
}

Which worked first try of course, on the 4th try.

And now that Fibonacci was working I had to go for the second milestone of interpreter development: Flappy Bird.

Step 4: So how do we see?

Well, first things first, we need a window.

Since this is my emulator, I get to make the rules. And I decided that a specific memory range would be dedicated to the framebuffer. One of the few places where I actually went with the simplest option yes. So at address 0x1000_0000, I placed a 1920x1080 RGBA framebuffer, so I could see the 16x16 pixel art of Flappy Bird in full HD.

Needless to say I got humbled FAST.

See at this point, my emulator was running at a solid 100 million instructions per second (MIPS!, which sounds impressive until you do the math.

A 1920x1080 framebuffer has over 2 million pixels. Even if we only spent 5 instructions per pixel (which is practically impossible), that's already 10 million instructions per frame, or 10FPS.

That's with math that's about as accurate as rounding PI to 10.

I know that I'm "speedrunning a CPU" but like.. it has to be at least usable you know?

So in a moment of weakness, in the middle of a uni lecture, I lowered the resolution to 640x360. Which brought the FPS from a theoretical 10FPS to about 40 real FPS.
For drawing a white background.

But 40 FPS ain't real time. That's AI-interpolated horrible animation framerate, not a usable GUI app framerate. So I got to optimizing, and the one thing that really improved the performance was the Instruction Cache.

The Instruction Cache

Before I explain that, let's look at the problem it solves first:

When decoding a RISC-V instruction, you don't really have a single number that tells you what the instruction does. Instead, you have these instruction shapes (like register-register, register-immediate, jump instructions) and only after you figure out the instruction shape you can decode the instruction itself.

For hardware, this is extremely fast. Since the main decoder only needs to know the shape of the instruction and then can send it to something that knows how to decode it.
For software, this is absolutely horrible.

For software, we first need to match on the shape of the instruction and then match on the actual instruction in order to execute it. But if you look like 5 lines above, you'll know that there's a solution to this. We can just cache the decoded instruction instead of decoding it on the fly every time. Let me introduce you to: The Instruction Cache

Basically, when were trying to decode an instruction we first hit up the instruction cache to see if it has already been decoded. If yes, then just execute that. If no, then decode it and put it in the instruction cache, then run it.

But how are we going to decide what to decode?

We could have a 1:1 mapping of our entire memory to instructions
our entire 64 bits of memory..?
Can't we just decode the code given to the emulator?
Well no. If we want to run actual OS code, it'll need to be able to load new programs at runtime
What about a HashMap?
A HashMap lookup every single instruction would probably reduce our 40FPS to 0.4
So what did I do?
Pages!

When loading a PC we can look at what page it's in and load that page to the instruction cache. And that works! But (not so) surprisingly, when implemented naively it's not much faster than just decoding on the fly.

The reason for this is that in the naive solution, we're checking the PC every time it moves to the next instruction, which is horribly slow and unnecessary considering most of the time we're just moving to the next instruction.

But if we're not checking the PC every time, how do we know that it has changed?

Here's the idea, let's say our pages are 1024 instructions (4KBs).
What if we inserted a fake instruction at the end of the page that tells us that we're at the end of the page. Kind of like a nul-terminated string!

Then we can go fetch the new page our PC is in.

And then for instructions that modify the PC directly (jumps, branches, etc.) we can just always fetch the page for the PC.

Of course I did add early-outs to that page fetch for the common case where the jump is in the same page but that's the general idea of the Instruction Cache.

After tinkering around with the Instruction Cache a bit more, instruction decoding became essentially free. Which is absolutely amazing, but I was still at only 65FPS.

The M extension

Next thing I implemented was support for more advanced operations. Such as multiplication (scary), and division!

This brought the performance up from 65FPS to about 80. Mostly because before this we were using a software implementation of division and multiplication.

Which means hundreds of instructions that got replaced with a single instruction.

And unfortunately I was out of ideas for how to make this any faster, so I had to accept that my emulator was only at 160MIPS, which is still amazing for a pure interpreter!
If I had that many MIPS back in the year 200 I would've been basically god.

This is about the time where I went back to the RISC-V test suite I mentioned a bit ago.

Step 5) Timeout

Originally, this section was going to be about how, on the very last day (the saturday right before this post went up) leddoo, completely unprompted, found a way to bump the interpreter from 160 MIPS to 540 MIPS. Purely interpreted.

And I was gonna talk about it.
I really was.

But then I wrote the title "Timeout" and realized: crap, I forgot to mention timers.

And listen-
I would very much rather not talk about whatever that was.
It apparently involved something called CSRs??

So that's it. Just like that my one-week CPU speedrun was over.
That's your ending. We're done here.

...

oh
What's that?
You're curious how we went from 160MIPS to 550?

Well that's awkward.
Honestly, I'd love to explain it. But it's 11:30PM, I haven't even made a thumbnail yet, and this post goes up at 9AM. Maybe I'll write about it in another post if enough people ask. For now, here's the repo

Here, I'll even make it easy to bother me:

My discord server, if you want to bother me about the deets this is probably the best place.
My E-Mail, probably not the best place but I do enjoy getting mails a lot. Makes me feel important

And hey, if you enjoyed this post consider buying me a cup of coffee.
I kinda forgot this was a "weekly blog" and got way too deep into emulator dev.
It happens.

Alright. Goodnight.

Voxel Engine in a Weekend

2025-11-08T08:59:03.535128220+00:00

It feels like everyone who learns how to make a voxel-engine learns it through sheer osmosis of information, so let's change that. Come along, let's make you a voxel engine!

Overview

Hello, are you ready? Because we're going to take you from a single cube to an entire voxel engine!
Here's what you'll need to bring:

Your own language! All the code examples are in pseudocode so unless you write a compiler for it you're not going to be able to copy paste it anyways, so pick something you like.
Your own rendering API! Pick whatever you want, this isn't a rendering tutorial.

If you have any questions during the process feel free to reach out to me on my discord server or contact me at contact@daymare.net.

If you're set, grab a drink and let's do this!

Maybe this should've been before Overview

Here's the contents of this post since I assume it'll be quite long.

Hello, cube
Meshes and Chunks
World Generation
- Voxel Types
Physics
- Raycasting
- AABB Collision
One last thing..
The End?
..or is it?

Hello, cube

I'm not planning on making the rest of the post so undetailed but rendering a cube is mostly a graphics task and if you're using OpenGL you only need to read 6 pages from LearnOpenGL to get to this point. So I'll assume you can handle this on your own.

By the end of it you should roughly have a function draw_cube that takes in a Vec3 position and draws a cube there. Here's mine:

And now, all that's left to do is place more cubes everywhere! A simple for loop should suffice

for z in 0..32 {
    for x in 0..32 {
        draw_cube(Vec3::new(x, 0, z));
    }
}

This should give us a one voxel tall 32x32 rectangle.

Now, instead of doing the for loop every time, let's put our voxels in a data structure and call it our World.
We can put a HashSet of positions here to know what world coordinates have a voxel.

Now depending on what programming language you're using you might not be able to put Vec3 in a HashSet. And even if you can, we should still be converting our float-based Vec3 into an integer-based IVec3 as that'll allow us to ensure that voxels are aligned to a grid. Which is important for foreshadowing reasons.

struct World {
    voxels: HashSet<IVec3>,
}

then, all we need to do is populate our world at the start

for z in 0..32 {
    for x in 0..32 {
        world.voxels.insert(IVec3::new(x, 0, z))
    }
}

and then every frame we can render our world like so

for voxel_pos in world.voxels {
    draw_cube(voxel_pos);
}

After all that you should have.. the exact same scene! But now we can do funky stuff like adding a random cube in the middle of nowhere by just adding it to our World

world.voxels.insert(IVec3::new(7, 2, 13))

We can even add and remove blocks at runtime. Let's make it so when we press Space the block we're standing in is created if it doesn't exist and removed if it does

if input.is_key_pressed(Key::Space) {
    var position = camera.position.as_ivec3();
    if world.voxels.exists(position) {
        world.voxels.remove(position);
    } else {
        world.voxels.insert(camera.position.as_ivec3())
    }
}

Now I encourage you to go experiment with this a bit; maybe change the dimensions of the initial platform, add weird structures etc. before continuing on.

Meshes and Chunks

If you've tried to increase the platform's size you might've noticed that the performance suffers greatly. This is because if you implemented the draw_cube function as naively as I have (without instancing) you'll be uploading & drawing 36*voxel_count vertices every frame. Which is a lot of data to be uploading to the GPU every frame.

What we can do is create a single Mesh for our world and only upload that once at the start. To do that we'll first need to add a Mesh to our world

struct World {
    voxels: HashSet<IVec3>,
    mesh: Mesh?,
}

The ? means that the Mesh can be none, this is because we won't have a Mesh at the start of the program.

and then when rendering we will

if world.mesh != none {
    draw_mesh(world.mesh);
} else {
    create_mesh(world);
    draw_mesh(world.mesh);
}

and create_mesh would look something like

fn create_mesh(world: &World) {
    var vertices = [];

    for voxel_pos in world.voxels {
        draw_cube(vertices, voxel_pos);
    }

    world.mesh = Mesh::from_vertices(vertices);
}

so now if you run it you should once again get the exact same scene. But! you might have noticed that now you can't modify the world anymore.

Ah, the joys of engine development. What we have done is cache our world Mesh on the first frame, but currently we don't have a way of invalidating it.
Which means even after we modify our HashSet we will be drawing the cached Mesh from the first frame.

Sounds intimidating but all we need to do is go back to our world modification code and set world.mesh to none

if input.is_key_pressed(Key::Space) {
    world.mesh = none;
    ...
}

Voilà!

Now we finally have the same thing we had 5 minutes ago.

Before we were drawing the entire world block by block, now we are drawing the entire world at once which comes with a brand new problem of its own, we need to rebuild the entire world whenever a single block changes.

Which sounds fine when our world is 32x32 but at something like 2048x2048? That's over four million cubes to rebuild just because one changed.

This leads to the second buzzword of this section: Chunks

But before we move onto that let's introduce a flip_voxel function on our World to make our job a bit more convenient.

fn flip_voxel(world: &World, position: IVec3) {
    world.mesh = none;
    if world.voxels.contains(position) {
        world.voxels.remove(position);
    } else {
        world.voxels.insert(position.as_ivec3())
    }
}

and then we can switch out our input to

if input.is_key_pressed(Key::Space) {
    flip_voxel(world, camera.position);
}

Basically, instead of treating the entire world as one giant data structure we split it up into smaller pieces called chunks.
Each chunk is just a mini-world, let's say 32x32x32 blocks big (the exact size doesn't really matter)

When you place or remove a block, you don't rebuild the whole world but instead just rebuild the chunk that the block is in.

Basically, we're building the world out of a bunch of tiny worlds that all work independently, which allows us to change one of them without changing all the others.

[a 2d image that shows a world being a single chunk vs split up into a 32x32 chunks]

All we need to do for implementing it is modify our World so that instead of storing every voxel in one big HashSet we'll group them by which chunk they belong to. Each chunk keeps track of its own voxels, and the world just tracks which chunks exist. We will also remove the mesh field from our world and move it to its chunk.

For all practical purposes we're just renaming our World into Chunk and creating a new World type.

struct World {
    chunks: HashMap<IVec3, Chunk>, // !!
}

struct Chunk {
    voxels: HashSet<IVec3>,
    mesh: Mesh?,                   // !!
}

For my implementation I'll say that a Chunk will start on (0, 0, 0) and end at (32, 32, 32). And our World will store our Chunks in chunk-space.

That means that the Chunk at (1, 5, 3) will span voxels from (1x32..2x32, 5x32..6x32, 3x32..4x32).

In order to convert from a world-position to a chunk position & a local position we'll need to do some math on it. We can divide our world-position by our chunk size (32) to get the position of the chunk that world position is in. Then we take the remainder (or modulus) of our world position by our chunk size (32) to find the chunk local position.

However there's something subtle but important we need to be wary of, negative numbers.

Take the world position (-7, 0, 0) for example, we want it to be on chunk (-1, 0, 0) with a local offset of (7, 0, 0). But in most programming languages if you just did what we talked about above you would get a chunk position of (0, 0, 0) with a local offset of (-7, 0, 0). The problem is that the chunk at (0, 0, 0) is double the size of all other chunks.

That's kind of annoying, in order to solve this we can use the euclidian versions of these operations, also known as floor division/remainder.

So let's look at how we'll need to change our flip_voxel function

fn flip_voxel(world: &World, position: IVec3) {
    var chunk_position = position.div_euclid(32);
    var local_position = position.rem_euclid(32);

    var chunk = get_or_create_chunk(world, chunk_position);

    chunk.mesh = none;
    if chunk.voxels.contains(local_position) {
        chunk.voxels.remove(local_position);
    } else {
        chunk.voxels.insert(local_position.as_ivec3())
    }
}

We'll need to create a get_or_create_chunk function, this'll make more sense later

fn get_or_create_chunk(world: &World, chunk_position: IVec3): &Chunk {
    if !world.chunks.contains(chunk_position) {
        world.chunks.insert(chunk_position, Chunk { mesh: none, voxels: HashSet::new() } )
    }

    return world.chunks.get(chunk_position)
}

Of course, we'll also need to remove the create_mesh function for our World and make one for our chunks. Okay I lied we're just gonna change the type parameter from World to Chunk.

fn create_mesh(chunk: &Chunk) {
    var vertices = [];

    for voxel_pos in chunk.voxels {
        draw_cube(vertices, voxel_pos);
    }

    chunk.mesh = Mesh::from_vertices(vertices);
}

and then update our rendering code. When rendering we'll need to offset the mesh by chunk_pos x chunk_size. Because, yk, we're just tiling these chunks.

for chunk_pos, chunk in world.chunks {
    var offset = chunk_pos * 32;
    if chunk.mesh != none {
        draw_mesh(chunk.mesh, offset);
    } else {
        create_mesh(chunk);
        draw_mesh(chunk.mesh, offset);
    }
}

I almost forgot, but we also need to change how we populated our world at the start

for z in 0..32 {
    for x in 0..32 {
        world.flip_voxel(IVec3::new(x, 0, z));
    }
}

world.flip_voxel(IVec3::new(7, 2, 13));

so for, hopefully but not likely, the last time we finally have the same thing we had 15 minutes ago.

phew, well that was a lot of work for not much visual pay-off huh?
I should probably take you through optimizing the mesh generation but before that, how about we take a look at some basic world generation instead?

World Generation

So the simplest world-generation might work with just making a flat platform on a certain Y-level, and with the setup we have it'll be trivial!

The first thing we'll need to do is modify our get_or_create_chunk function (see I told you it'd be important later!)

So far it's been responsible for creating empty chunks when we needed them. But now we can start to use it to also generate those chunks when needed.
Whenever a new chunk is generated, we'll stuff it with some terrain. In this case that terrain is just "flat". It's not glamorous but hey, something something Rome wasn't built in a day and I did say this is going to take a weekend.

fn get_or_create_chunk(world: &World, chunk_position: IVec3): &Chunk {
    if !world.chunks.contains(chunk_position) {
        
        var voxels = HashSet::new();
        if chunk_position.y == 0 {
            for z in 0..32 {
                for x in 0..32 {
                    voxels.insert(IVec3::new(x, 0, z));
                }
            }
        }

        world.chunks.insert(chunk_position, Chunk { mesh: none, voxels } )
    }

    return world.chunk.get(chunk_position)
}

If you just ran this code you might've noticed that the world is looking kinda empty . That's because we don't generate any chunks that aren't being modified and so to fix this we need to introduce the concept of a render distance.

The idea is simple: pick a radius around the camera and touch 'em all.

I could bore you with a dozen different ways to do this efficiently, or we can just touch everything every frame. Which is fine, probably.

So let's go back to our rendering loop and tweak it. We need to offset our radius so that it's around the camera, in order to do that we can just offset it by the chunk the camera is in.

var radius = 4;

var camera_chunk = camera.position.div_euclid(32);

for y in -radius..radius {
    for z in -radius..radius {
        for x in -radius..radius {
            var chunk_offset = IVec3(x, y, z);
            var chunk_pos = camera_chunk + chunk_offset;

            var chunk = get_or_create_chunk(world, chunk_pos);
            
            var offset = chunk_pos * 32;
            if chunk.mesh != none {
                draw_mesh(chunk.mesh, offset);
            } else {
                create_mesh(chunk);
                draw_mesh(chunk.mesh, offset);
            }
        }
    }
}

And there it is! A flat, infinite plane. Not much to look at, but hey, at least it’s not the same thing we’ve been staring at for the past few sections.

Except, do you see that giant hole too? Okay so that's our old "world generation" code sort of colliding with our new one. We can just remove that part and be fine.

I think this might be the perfect time to take a tiny detour and talk about Voxel types.

Voxel Types

So far our world has been made up of a HashSet of voxels where a voxel either exists or it doesn't, but that's kinda boring so let's give our voxels some personality.

We'll start by creating an enum called VoxelKind. You can obviously call it whatever you want. Bonus brownie points if you call it WoahThisIsVeryCool.

enum VoxelKind {
    Dirt,
    Stone
}

and then replace our HashSet with a HashMap

struct Chunk {
    voxels: HashMap<IVec3, VoxelKind>, // !!
    mesh: Mesh?,
}

We'll still treat the absence of a value as air/nothing.
But yeah, that's basically all we need to do in order to support multiple voxel types.
Apart from, you know, the dozen or so spots in our code that will now immediately break.

Let's take it from the top of my file.
First, we need to change our flip_voxel function alongside renaming it because well, you can't really flip a Dirt block can you? I'll rename it to set_voxel or something.

fn set_voxel(world: &World, position: IVec3, kind: VoxelKind?) { // !!
    var chunk_position = position.div_euclid(32);
    var local_position = position.rem_euclid(32);

    var chunk = get_or_create_chunk(world, chunk_position);

    chunk.mesh = none;
    if kind == none {                                         // !!
        chunk.voxels.remove(local_position);
    } else {
        chunk.voxels.insert(local_position, kind)    // !!
    }
}

then our get_or_create_chunk function of course

fn get_or_create_chunk(world: &World, chunk_position: IVec3): &Chunk {
    if !world.chunks.contains(chunk_position) {
        
        var voxels = HashMap::new();                            // !!
        if chunk_position.y == 0 {
            for z in 0..32 {
                for x in 0..32 {
                    voxels.insert(IVec3::new(x, 0, z), VoxelKind::Dirt); // !!
                }
            }
        }

        world.chunks.insert(chunk_position, Chunk { mesh: none, voxels } )
    }

    return world.chunk.get(chunk_position)
}

and our create_mesh function as well, of course this will need to come with a change to your draw_cube function but since this isn't a rendering tutorial I'll just pass in the VoxelKind and leave the colouring up to you.

fn create_mesh(chunk: &Chunk) {
    var vertices = [];

    for (voxel_pos, voxel_kind) in chunk.voxels {    // !!
        draw_cube(vertices, voxel_pos, voxel_kind);  // !!
    }

    chunk.mesh = Mesh::from_vertices(vertices);
}

our input needs to change as well

if input.is_key_pressed(Key::Space) {
    set_voxel(world, camera.position, VoxelKind::Stone);
}

and then everything should be working!

We can also modify our world generation so that it generates stone blocks below Y=0, dirt blocks at Y=1 and air on top of it.

I'll change up the loop a bit to make it easier for you to modify it later and add your own stuff!

fn get_or_create_chunk(world: &World, chunk_position: IVec3): &Chunk {
    if !world.chunks.contains(chunk_position) {
        
        var voxels = HashMap::new();

        for z in 0..32 {
            for y in 0..32 {
                for x in 0..32 {
                    var offset = IVec3::new(x, y, z);
                    var world_voxel_position = chunk_position * 32 + offset;

                    if world_voxel_position.y == 0 {
                        voxels.insert(offset, VoxelKind::Dirt);
                    } else if world_voxel_position.y < 0 {
                        voxels.insert(offset, VoxelKind::Stone);
                    }
                }
            }
        }

        world.chunks.insert(chunk_position, Chunk { mesh: none, voxels } )
    }

    return world.chunk.get(chunk_position)
}

And with that, our world generation is complete! It's not very pretty but I'll leave the artistic part to you.

Now, if you played around with it a bit, you might've noticed that it's painfully slow.
I was hoping to let you run wild for a bit and save the performance talk for later, but looks like we're dealing with it now.

Here's the thing, you might assume that the problem is the HashMap we're using for each voxel and while that is a part of the problem the bigger problem is that we're generating way too many unnecessary faces.

If you look around in your world and maybe try going into the ground you might notice that there's faces being drawn in-between blocks where it wouldn't even be visible!

You might've also seen weird artifacting when looking at the ground, those hidden faces are also the reason for that.

What do we do, you may ask. Well first I'll need you to make your draw_cube function into a draw_quad function because we'll need to draw one face at a time not all 6. After that, the change is quite simple

All we need to do is update our create_mesh function so that for every face we check that there's no voxel in that direction.

fn create_mesh(chunk: &Chunk) {
    var neighbours = [
        (IVec3::new( 1,  0,  0), Direction::Right),
        (IVec3::new(-1,  0,  0), Direction::Left),
        (IVec3::new( 0,  1,  0), Direction::Up),
        (IVec3::new( 0, -1,  0), Direction::Down),
        (IVec3::new( 0,  0,  1), Direction::Forward),
        (IVec3::new( 0,  0, -1), Direction::Back),
    ]
    var vertices = [];

    for (voxel_pos, voxel_kind) in chunk.voxels {
        for (offset, dir) in neighbours {
            if !chunk.voxels.contains(voxel_pos + offset) {
                draw_quad(vertices, voxel_pos, voxel_kind, dir);
            }
        }
    }

    chunk.mesh = Mesh::from_vertices(vertices);
}

And that's it! By only drawing the faces that are actually visible, we've just reduced our vertex count by up to 90%!

Now, I'll let you play around with this for a bit. Move around, mess with the world generation (maybe try perlin noise!), have fun with it and when you're back we'll add some physics.

Physics

We're in the final stretch now. Let's start by adding a little bit of interactivity by adding raycasting

Raycasting

Our goal is to make it so we can place & break blocks that we're looking at.
To do that, we need to raycast from our camera aka shooting a line from the camera to the world to see which voxel collides first.

Raycasting is a topic that you can really deep-dive into, heck maybe it's a deeper topic than voxel engines itself.
However, the raycasting we need for a voxel engine is really simple. Since our world is a grid we can just step through each voxel one by one in the direction we're looking at.

This is usually called a DDA (Digital Differential Analyzer) raycasting. Here's the idea:

Start from the camera's position
Figure out how far you need to go in each axis (x, y, z) before you cross into the next voxel
Every step, move in the axis that's closest
Repeat until you hit something

We will also track the last move we've made in each step so we can figure out which side of the voxel we're looking at.

If you're not following any of this, don't worry me neither. All that matters is that the code we need is:

fn raycast_voxel(world: &World, start: Vec3, direction: Vec3, max_dist: float): (IVec3, Vec3)? {
    // the voxel we're standing in
    var pos = start.floor().as_ivec3();
    // which way we're stepping (+1 or -1 for each axis)
    var step_dir = direction.sign()

    // how far to step in each axis (smaller means steeper)
    var delta = abs(1 / direction)

    // how far from the current pos to the next voxel boundary
    // for example, if we're 0.3 into a voxel and going positive X,
    // we have 0.7 to go before hitting the next voxel wall.
    var fract = start - pos.as_dvec3();
    var t_max = Vec3::new(
        if dir.x > 0.0 { 1.0 - fract.x } else { fract.x } * delta.x,
        if dir.y > 0.0 { 1.0 - fract.y } else { fract.y } * delta.y,
        if dir.z > 0.0 { 1.0 - fract.z } else { fract.z } * delta.z,
    )

    var dist = 0.0;
    var last_move = Vec3::ZERO;

    while dist < max_dist {
        if get_voxel(world, pos) != none {
            return (pos, -last_move.normalize());
        }

        // a bunch of fancy maths
        // step in the axis with the smallest t_max — that's the next voxel boundary
        if t_max.x < t_max.y && t_max.x < t_max.z {
            pos.x += step.x;
            dist = t_max.x;
            t_max.x += delta.x;
            last_move = Vec3::new(step.x, 0.0, 0.0);
        } else if t_max.y < t_max.z {
            pos.y += step.y;
            dist = t_max.y;
            t_max.y += delta.y;
            last_move = Vec3::new(0.0, step.y, 0.0);
        } else {
            pos.z += step.z;
            dist = t_max.z;
            t_max.z += delta.z;
            last_move = Vec3::new(0.0, 0.0, step.z);
        }

    }
    none
}

Now you'll be missing the get_voxel function, that'll look very similar to our set_voxel function but simpler

fn get_voxel(world: &World, position: IVec3): Voxel? {
    var chunk_position = position.div_euclid(32);
    var local_position = position.rem_euclid(32);

    var chunk = get_or_create_chunk(world, chunk_position);
    return chunk.voxels.get(local_position);
}

That’s it! Now you can raycast from the camera and get which voxel you’re looking at, plus which face you hit. This will come in handy when you want to do something crazy like... break a block or place one next to it.

So let's do that. We can delete the code that used the space key to place a voxel and replace it with something like

if input.is_mouse_button_pressed(MouseButton::Left) {
    var result = raycast_voxel(world, camera.position, camera.direction, 3)

    if result != none {
        var (target_block, _) = result
        world.set_voxel(target_block, none)
    }
}

and now we can break blocks! We can do something similar for placing blocks as well, and this is where that last_move value will be useful

if input.is_mouse_button_pressed(MouseButton::Right) {
    var result = raycast_voxel(world, camera.position, camera.direction, 3)

    if result != none {
        var (target_block, last_move) = result
        world.set_voxel(target_block + last_move, Voxel::Stone)
    }
}

Just like Minecraft, and every game that tried to be like Minecraft (don't @ me)

With this, you can now interact with your world in a much less jank way. And hey, you just did raycasting. Here, take some brownie points because I hated every part of that.

AABB Collision

And lastly, collision. This one is also a potential rabbit hole, honestly all of physics is, but it's also quite simple since our world is made up of voxels.

We're going to be handling AABB (Axis-Aligned Bounding Box) collision with our world. So all we care about is whether or not this box is intersecting with the world, if it is, then don't move there.

Firstly, we'll need to give our camera a hitbox. Let's go with the dimensions (0.8, 1.8, 0.8) for absolutely no reason other than hey Minecraft uses something similar.

Then, wherever your camera movement code is you'll want to set it to a variable new_position before updating the camera's true position. So that we can check that the new position isn't inside anything

After that we can look at our algorithm.

Basically, first we calculate the delta of our new position and our old position. This gives us a vector telling us how much we should move in each axis.

Then we can just apply this movement vector for each axis, check that the new position isn't inside a voxel and then commit it to the camera's position.

If it is inside a voxel then we can just cancel out the movement in that direction.

A simpler way to do collision probably would've been to just check after the entire movement but then you wouldn't be able to walk against a wall so it's not really nice to play around with.

And then there's the actual AABB logic. Basically what we're going to do is expand our camera's AABB into our voxel grid.

After that we can just check that everything inside that box is air.

We'll assume our camera position is at the centre of its AABB

Anyway, here's the algorithm:

// ..
// new_position should be defined above

var aabb_dims = Vec3::new(0.8, 1.8, 0.2);
var aabb_half_dims = aabb_dims / 2;
var delta = new_position - camera.position;

for axis in 0..3 {
    var target_position = new_position;
    target_position[axis] += delta[axis];

    var min = (target_position - aabb_half_dims).floor();
    var max = (target_position + aabb_half_dims).ceil();

    var collided = false;
    for x in min.x..max.x {
        for y in min.y..max.y {
            for z in min.z..max.z {
                var position = IVec3::new(x, y, z);
                if get_voxel(world, position) != none {
                    collided = true;
                    break;
                }
            }

            if collided {
                break;
            }
        }

        if collided {
            break;
        }
    }


    if !collided {
        camera.position[axis] = target_position[axis];
    }

}

Can't lie, I'm probably not the best person to teach physics but I had to include it. After all, who cares about a world you can't interact with.

But now, you can interact with it. And you can move around in it.

One last thing..

So I left this for the end intentionally since it complicates things but I can't avoid it anymore, let's take a look at our Chunk structure

struct Chunk {
    voxels: HashMap<IVec3, VoxelKind>,
    mesh: Mesh?,
}

We're using a HashMap to store our voxels, however this is a really bad idea for several reasons the most important being that it's really bad for performance.

Instead, since our chunks are 32x32x32 (meaning that the IVec3s in the HashMap are always within the range of [0, 32)) we can replace our HashMap with a 3 dimensional array.

To do that, let's add an Air type to our VoxelKind first

enum VoxelKind {
    Air,
    Dirt,
    Stone
}

then we can change our Chunk to have a 3D array

struct Chunk {
    voxels: [[[VoxelKind; 32]; 32]; 32],
    mesh: Mesh?,
}

Note: I'm indexing as [y][z][x] here, but feel free to swap it with [x][y][z] if it makes more sense for your brain.

Obviously this will cause a lot of errors to pop up in your code. What you'll need to do is replace all usages of accessing our voxels data with using our set/get helper functions

However, those functions do need a little bit of a rework as well

Our set_voxel function will no longer take an optional VoxelKind but instead just take the VoxelKind itself since we use VoxelKind::Air for absence of a voxel now.

fn set_voxel(world: &World, position: IVec3, kind: VoxelKind) { // !!
    var chunk_position = position.div_euclid(32);
    var local_position = position.rem_euclid(32);

    var chunk = get_or_create_chunk(world, chunk_position);

    chunk.mesh = none;
    
    chunk.voxels[local_position.y][local_position.z][local_position.x] = kind
}

then our get_voxel function will be

fn get_voxel(world: &World, position: IVec3): VoxelKind { // !!
    var chunk_position = position.div_euclid(32);
    var local_position = position.rem_euclid(32);

    var chunk = get_or_create_chunk(world, chunk_position);
    
    chunk.voxels[local_position.y][local_position.z][local_position.x]
}

After this you'll be able to make it all work yourself I'm sure. All but the get_or_create_chunk function and create_mesh function.

Let's take a look at how get_or_create_chunk changes

fn get_or_create_chunk(world: &World, chunk_position: IVec3): &Chunk {
    if !world.chunks.contains(chunk_position) {
        
        var voxels = [[[VoxelKind::Air; 32]; 32]; 32]; // !!
        if chunk_position.y == 0 {
            for z in 0..32 {
                for x in 0..32 {
                    voxels[0][z][x] = VoxelKind::Dirt;
                }
            }
        }

        world.chunks.insert(chunk_position, Chunk { mesh: none, voxels } )
    }

    return world.chunk.get(chunk_position)
}

That was an obvious fix I know, but then there's the create_mesh function, which has one important gotcha that you might miss.

In our create_mesh function we were only drawing a face if the neighbour didn't exist (now it'd be if it's VoxelKind::Air) but since we were using a HashMap we didn't need to care if the neighbour was outside of our chunk.

Now we do. So we'll need to add an is_oob flag to the loop, and if the neighbour is out of bounds (meaning that it's either in the negatives or greater than 32) we'll treat it as if it was Air. Effectively the same as the old version.

fn create_mesh(chunk: &Chunk) {
    var neighbours = [
        (IVec3::new( 1,  0,  0), Direction::Right),
        (IVec3::new(-1,  0,  0), Direction::Left),
        (IVec3::new( 0,  1,  0), Direction::Up),
        (IVec3::new( 0, -1,  0), Direction::Down),
        (IVec3::new( 0,  0,  1), Direction::Forward),
        (IVec3::new( 0,  0, -1), Direction::Back),
    ]
    var vertices = [];

    for (voxel_pos, voxel_kind) in chunk.voxels {
        for (offset, dir) in neighbours {
            var np = voxel_pos + offset;
            var is_oob = np.any(|axis| axis < 0 || axis >= 32);


            if is_oob || chunk.voxels[np.y][np.z][np.x] == VoxelKind::Air {
                draw_quad(vertices, voxel_pos, voxel_kind, dir);
            }
        }
    }

    chunk.mesh = Mesh::from_vertices(vertices);
}

The END!

And ta da!!!

You have a voxel engine! You started with a single cube and now you got chunks, raycasting, physics, and an infinite world. Every voxel engine looks the same at first, so go make it yours.

And please please please show it off to me on my discord server or contact me at contact@daymare.net.

If you found this post useful, consider tossing me a coin

or is it?

But we all know that this isn't the end but the beginning. Here's a few challenges if you dare take it upon yourself, I ordered them with my completely arbitrary scale of difficulty

Gravity & Jumping: We have physics, why not make it actually playable!
Offset the camera's AABB: Right now we assume the camera is in the centre of its AABB, it's simple but it doesn't really feel right. Your head is higher than the middle of your body, so try to change that
Procedural Terrain: I didn't touch upon this in the world generation section since it's more the artistic part of voxel engines but you should definitely take a look, give your engine some personality. The setup I gave you with get_or_create_chunk should make it super trivial to add new stuff. Hint, look into using a 2D perlin noise texture as a height map.
Save & Loading: I was planning on including this in the article itself but it's already long enough so I'll leave it as a challenge for you. Start with saving your chunk data to a binary file and load it in the get_or_generate_chunk function. After that, you could look into region based loading as well if you're curious.
Unloading invisible chunks: Any chunk outside of the render distance can be unloaded to the disk instead of wasting memory, try periodically checking if the chunk is within the render distance and if not unload it.
Removing the faces between chunks: You might've noticed from before we added physics that even though we optimized our mesh by a lot there's still more invisible faces in-between chunks. It's not too hard to remove those as well, your create_mesh function will need to know about the surrounding chunks as well. After this is also a pretty good place to stop with the mesh optimizations.
Frustum Culling: Right now we're drawing every chunk within the render distance even if it's behind us. Try adding frustum culling to only draw the chunks that are actually visible.
Ambient Occlusion: There's this really great article on ambient occlusion for voxels, check it out it really changes the whole vibe of your world from plastic barbie land to an actual world
Textures!: So far I've been using plain colours for my voxels, and I can only assume you've been doing the same. So try adding textures, maybe even a texture atlas.
Greedy Meshing: So, you didn't heed my warning. That's fine, here is your path soldier
Lighting, of course: After ambient occlusion it's only natural that you try to do lighting. For minecraft style lighting here's an article you could check out. Hint, one difference you might notice is that while Minecraft's chunks are 16x256x16 our chunks are 32x32x32. But in order to implement that lighting system you'll need to determine a height limit.
Speed, speed, speed: SPEEEEEED
Octrees: For when HashMaps of chunks are too slow.
Multithreading: Here be dragons. Async chunk generation, chunk meshing, cache invalidation, all that and more awaits you. But if you do dare take upon this quest, you better know that the result feels incredible.
Regions: Okay this one isn't actually the hardest but for you to get any use out of it your voxel engine already needs to be stupidly fast. HashMaps are really slow with a lot of entries, so try to group your chunks into 32x32x32 regions. Chunk-ception or something.
Chunk Unloading v2: More dragons. You might've noticed that your voxel engine is using a lot of memory at high render distances, that's because each chunk is at least 32768 bytes (assuming each voxel is 1 byte). But let me tell you a secret, you don't need to have the voxel data of the far away chunks loaded. You can just generate the mesh and unload the data for it. Have fun with this information as you will, it's the difference between 96 render distance using 230+GBs of memory vs 3GBs (true story)
???: Who says voxels need to be on the CPU?

So I became God: Artificial Life

2025-11-02T07:50:02.679417958+00:00

Let me take you through a journey of curiosity, growth, and cannibalism. One inspired by a video game and some questionable media..

About a year ago, I watched the Black Mirror episode "Plaything" (awesome ep. btw). I didn't think much of it then but it was my introduction to the idea of artificial life.

Obviously, even before then I'd seen the fancy YouTube videos, you know the "I made an ecosystem in Unity!" ones. But again, still nothing.

Until I saw a roguelike called Primordialis. It's this physics-based roguelike where you design your own creature out of cells (muscles, spikes, electric organs, etc.). And your enemies are also designed in the same way. Now I don't know if you see the vision but if you do, you already know what's coming.

While playing the game I just couldn't help but imagine a world with the same rules of Primordialis, one where the creatures can evolve not only their tiny lil brains but also their body.

So I became God.

The first day

In the beginning, there was nothing.
And before there was nothing, there was ~~MONSTERS~~ Rust.

Of course, the first step was to decide what our little goobers (that's the name I called them in the code, yes) would be made out of. The elements, if you will.

But before I could even start on the fancy simulation I needed to fill this one glaring hole in my knowledge. I had never touched a neural network in my life!

So I did what every responsible dev does, I went on YouTube and learned about them. I'm kidding, I just asked ChatGPT to explain it to me. Then I decided to write my own version, because honestly that sounded easier than using Rust libraries¹. I made the simplest of feed-forward neural networks.

The first goal was simple, collect all the apples as fast as possible.

It went in the most boring way ever, it went alright. I had about 100 agents running for 5ish minutes and it had already perfected everything.

Which, while a little disappointing, meant that I had the green light to go ahead and work on the fancy simulation now.

The second day

Let there be motion.

Previously, each goober had its own instance. But now they'd have to share the same resources.
And for them to actually care about those resources, there had to be stakes.

The rules of life were simple:

Eat, you reproduce.
Move too fast, you get hungry.
Get too hungry, you die.

The goobers also got a vector pointing in the direction of the nearest food, ah the simpler times. Of course, when they reproduced there was a small chance to evolve their brain.

And then, the great blinding occurred. After that instead of having a direction to the nearest food, they would have to see.

I made it so each goober had to shoot out 8 rays at slightly different angles in order to see². It'd return a 1 if it was food, -1 if it was another goober and 0 if there was nothing.

As you can (maybe) see, strategies were starting to develop. Some went with the strategy of vibrating in place, some went with the strategy of hunting food, and some went with the strategy of going as fast as fucking possible, hoping they'd hit some food before they died.

Well, it's cool 'n all but single cells are BORING.
So after that little experiment was over I was ready to move onto multicellular organisms, also known as drawing more than one rectangle.

So I went back to isolated worlds, which started with the goobers being able to modify their velocity directly.

Which then led to me restricting their movement to "Look Left/Right" and "Move forward"

Are they stupid?
Yeah.
They're trying, okay

The third day

Let there be... fat people?

Now that we have goobers, and they can move around, eat food, and reproduce we can finally get to the entire point of this project and give them more cells to work with.

At first I had very simple cell types that were basically stat modifiers. There was a SpeedyCell that increased your max speed & decreased how much energy you lost from speeding. Or a basic cell that just increased your mass.
Oh and also a HealthyCell which decreased the basal metabolic rate and fat cells that could increase the maximum energy they could store.

And uh.. that was sorta it for a bit but I'll get to that later.³

Of course cells came with some drawbacks as well. Each cell would increase your mass and weight, the heavier you got the slower you could move and the more energy it took to do the same actions.
Which obviously, led to the sword meta.

So uh, this is about the point where I started to fear I created a cult. But obviously the swords had to be stopped.

My mate Kiniro (the dev of the game Faster Bunnies) suggested a great fix: make goobers grow to their full size before they can spawn children.

Which actually worked!

Except now they were just not growing at all.

So I thought: well, if these guys don't want to grow, I'll just let them fight it out.

And on the fourth day..

I let them fight.

I gave them weapons (Spike cells). I gave them shields (..shield cells). But most importantly, I gave them an incredible 12 floats of memory⁴ so they could avenge their father.

Combat wasn't random either, getting hit on the side dealt more damage than getting hit on the head. And every collision damaged both sides. I thought they'd learn to be strategic about it, angling attacks & dodging, but it mostly just led to the big guys eating their babies for food.

Evolution is a cruel thing, huh?

On the fifth day

the scientists who studied the rivers
were forbidden to speak
or to study the rivers.

Which is totally irrelevant. I just didn't have a better way of ending this post.

This was a really fun experiment that I'm definitely planning on returning to⁵.

If you enjoyed it, laughed, or want to join the cult of rectangles. Maybe buy me a coffee?
Or if you would like to fork around here's the repo. If you have any questions or feedback feel free to join my discord server or mail me at contact@daymare.net

¹: Related: Everybody's So Creative!

²: To be honest the way I handled raytracing was horribly inefficient. I've made raytracers before so I know that they can be fast, it's just that I really could not care less about it. I wonder how many hours of simulation time I could've saved had I only made it slightly more optimized by just adding a spatial grid or something

³: After reproduction each goober had a small chance to mutate their neural-network and/or delete/add/modify one of their cells.

⁴: I felt like a genius coming up with this idea, though I have no idea if the neural networks ever used it. It's basically just 12 floats that get passed into the neural-network and then are preserved for the next iteration. Yes, that's what I called "memory". You know, so they could store information about life's most important questions such as "Is this food?", "Is this enemy?", "Am I food?", etc.

⁵: Okay this one probably could've been inlined but I wanted to talk a bit more about it after I had already finished writing. I think the biggest failure of this experiment was that the goobers never really got a chance to live, their really short life revolved around "eat food as fast as possible" with nothing else they could do. Maybe in another iteration I could allow them to build, move food around, live 5 mins on a single piece of food instead of 30 seconds and just be more patient with them. There's a lot of ground to explore here.⁶

⁶: I really enjoyed writing these footnotes and this entire post in general, can you tell?⁷

⁷: Fun fact, the videos and screenshots for this post were taken months before I even had the idea for the website. So it's a total coincidence that the colours fit so perfectly.. wait is my favourite colour green??

This week in margarine

2025-10-26T06:46:11.276630437+00:00

A quick update on the progress of my programming language margarine. It's build system, why it won't have a JIT, and other design decisions.

For those who don't know margarine, it's my programming language that's meant to be a replacement for Lua in my own projects, check out this post if you want to learn more about it.

Hello! So here's the thing, this week I decided that I wanted to be done with margarine as soon as possible. But I'm also quite tired of having way too many unfinished projects, so I had to decide on a to-do list that I needed to finish before I could call margarine done. And before you click off, a JIT was in this to-do list until yesterday.

Here, I'll show you the to-do list.

a basic JIT
finishing up the build system
a GC
some bug fixes
stdlib

So me being me I went with the one I have never done before, the JIT.

The JIT

In a previous version of margarine I had used LLVM¹ to compile to native code and as far as I remember it was a horrible experience. Heck when I went back to margarine it didn't even compile even though literally nothing about my build system had changed.

So this time I decided to use something easier, something shinier, something newer, something called Cranelift. Which claims to be faster than LLVM while admitting that it has less optimisations. That sounds like a good trade-off, right? It probably doesn't have many of the niche optimisations that LLVM has built up over the years but it has the important optimisations, right?

That sounded amazing! Not only did it mean that I didn't need to deal with LLVM's jankness but also that the JIT will compile code faster!

Now, I don't need margarine's JIT to be perfect or even optimized. I just want to add a JIT to the runtime to make it faster and I want to get it over with quickly so I could move onto the next thing in the to-do list. So I just made the JIT convert my interpreter one-to-one.

I think this'll make more sense if I showed some code, so let's take the AddInt instruction. (fyi, margarine's interpreter is a stack based interpreter)

AddInt => {
   let rhs = stack.pop().as_int();
   let lhs = stack.pop().as_int();
   stack.push(Value::Int(lhs + rhs))
}

and so the JIT would just do that exact same thing but inlined. Which made the JIT the same as the interpreter except without the instruction over-head and any optimisations Cranelift could apply along-side it.

Now this meant that the JIT would often generate redundant loads and stores, stuff like store x then immediately override x. Which was fine, I thought. It sounds like a basic optimisation, surely Cranelift wouldn't even break a sweat, right?

Other than the fact that this isn't much of a basic optimisation, Cranelift doesn't even try to do anything about it. So I was left on my own.

Is this an unsolvable problem? No. Is there nothing I can do about it? Certainly not. Is this a problem I wanted to have when I decided to JIT? No, but it is what it is.

So I got onto brainstorming how I could go about solving this. For one, I could switch to a register based VM which would immediately eliminate any interaction with the stack since I can just use cranelift variables. But this would probably require me to rewrite my entire VM and some form of register-allocation would be practically necessary to keep the register count under 256 (one byte).

Or I could convert the stack into cranelift variables at runtime, though that would require me to know the stack height at any given instruction. The idea would be to convert each stack slot to a Cranelift variable and simulate push & pops.

There's many ways I could make this JIT thing work, but after talking to people I'm not sure if it's even worth it. Sure, it'd make things faster but there's a lot more I should be focusing on right now (many things that when implemented would probably require the JIT to be reworked anyways).

So I moved onto the next item on the list.

¹: Writing this some part of me wishes I never ditched compiling to native code. I know it was the right decision but the speed is very alluring especially now that I don't even have a JIT. Woman in the red dress or something I dunno.

The build system

This part of margarine has gone through a few iterations already. At the start, I just had to specify every single file I wanted to include in the CLI tool, which led to commands like

margarine std std/duration std/list std/rand raylib raylib/keys raylib/window flappy_bird

This ability to be extremely granular on what files to import was a design decision that I wanted to preserve since margarine is meant to be an embeddable language. But of course, we also need margarine to stand on its own, so I had to figure out something else.

The first thing I tried was to just copy Rust. I had a build.toml file where you could specify your dependencies, and your code would be in a src/ directory with the entry point being a function named main in src/main.mar.

This worked for a bit; the CLI tool would fetch the github repos of the dependencies, cache them in an artifacts/ folder and compile and then run the program. But I wanted more, because if we're creating this entire build system, we might as well make it more powerful.

That brings us to build.mar. When compiling, the std library is always included, and then the build function is called. The std library exposes the CompilationUnit type, an object that represents the current program's files and dependencies.

fn build() {
 var unit = CompilationUnit::new();
 unit.fetch("somelib", "https://some.other/library");
 unit.import("std/");
 unit.build();
}

This version isn't final because it doesn't handle libraries having dependencies. My current idea is to change the build function's signature to fn build(): CompilationUnit, letting libraries return their dependency info, allowing the creation of a single unit recursively.

Side note, here's a funny thing I discovered while working on this. Since margarine can run with compiler errors, as long as you don't actually execute the errors, you can actually compile the current file with new libraries.

fn build() {
 var unit = CompilationUnit::new();
 unit.fetch("rand", "https://github.com/todaymare/margarine-rand");
 unit.import("");
 unit.build()
}

fn main() {
   print(rand::rand())
}

which will work perfectly fine. Apart from spamming your terminal with compiler errors.

Back to the build system, another thing I recently considered was to go with Go style imports. You know, just

extern "https://github.com/todaymare/margarine-std" as std

in the middle of the program. This would allow me to not have a build system, but I'm not sure. I'll have to think more about this whole build system thing.

It's kind of annoying to constantly be working on things that aren't guaranteed to be finished, so I just decided to quickly write up something that's very important and is pretty much as complete as I'll ever make it be

The GC

is garbage collection just a metaphor for letting go?
- William Shakespeare

We're coming to the end of the week and while I have experimented with a lot of things I wouldn't call those two complete just yet. However, the garbage collection for margarine is complete. It's definitely not the fastest or the most optimal but it does clean up garbage when needed so it's fine.

What I did you might ask? I just copy-pasted the garbage collection I had for my old project azurite. I know I know lame! It's just a basic mark & sweep world-stopping tracing garbage collector.

There isn't much to say about it. It just goes through the stack, marks objects as live and then kills any that are dead. Oh and I guess it's only called when you fail to allocate an object.

End of the Week

Anyway, that's where margarine stands this week. A tiny bit more of a real boy.

Thank you for reading so far and if you enjoyed this post or have feedback on any of the design decisions I talked above consider joining my discord server, or you can e-mail me at contact@daymare.net. Or if you really enjoyed it, consider buying me a cup of coffee

Everybody's so Creative!

2025-10-19T08:39:24.740553972+00:00

After 4 years with Rust, I love the language – but I’m starting to think the ecosystem has an abstraction addiction. Or: why every Rust crate feels like a research paper on abstraction.

Hi, it’s me again. Back at it with another rant thinly disguised as a "think piece."

The Question Nobody Wants to Answer

Have you ever wanted to build something simple in Rust? Maybe you reach for bevy, or wgpu, or some other library that promises everything you didn't ask for.

And then you hit that moment – you're debugging, you hit "Go to Definition", and suddenly you're free falling through ten layers of traits, macros, and generics just to figure out how a buffer updates.

If that sounds familiar, congratulations: you've met Rust's favourite pastime – abstraction as performance art.

Why Are We Like This?

I get it – abstractions are cool. They’re supposed to hide complexity so we can focus on cooler stuff. And Rust loves that idea. Traits, generics, lifetimes – layer upon layer of "don’t worry about it honey."

Take nalgebra. Fantastic crate – powerful, flexible, and deeply overqualified for 90% of use cases.

It’s not that I hate nalgebra – it’s brilliant. I just hate that this kind of maximalism has become the default.

Want to do something slightly off-script?
That’ll be three trait bounds, one custom derive, and a spiritual journey through src/internal/utils/mod.rs

You might say these libraries are built this way because we don’t know what the user might want – and fair enough, that’s been the curse of library design since the dawn of libraries. But not every problem needs a skyscraper of abstractions; most of the time, all you need is a shed.

Take glam, for example, which doesn’t try to solve philosophy – it just does math. You don’t need a PhD in generics to understand what Vec3::normalize() does, and that’s exactly the point.

But the thing is – nalgebra isn't an isolated example. It’s cultural.

And that’s the real cost of abstraction – it makes the ceiling higher, but it also makes the floor invisible. (Shakespeare got nothin’ on me)

The real tragedy? Once you see it, you start writing that way too. You start thinking, "Well, maybe I should make this generic in case someone wants to use quaternions instead of matrices..." and suddenly, congratulations – you're building for someone who doesn't exist.

Rust, the Language

Rust is a great language. I’ll be the first to say that. It’s not perfect – no language is except margarine – but it’s the tool I reach for first.

That said, the Rust ecosystem feels like it's divided into two sides. (Ironic, isn’t it?)

On one side, you’ve got artists. The folks who treat Rust like an art form – every crate is a masterpiece of generics, lifetimes, and zero-cost abstractions. They push the language to its limits, and honestly? It’s incredible to watch.

On the other side are the people trying to ship things, the ones who’d use Zig if it weren’t allergic to syntactic sugar. They don’t care about elegance or clever abstractions – they just want their code to compile before they age into retirement.

That phrasing sounds harsh, but the thing is: neither side is wrong.

Let's get one thing straight: over-engineering in Rust is incredibly fun. The language hands you these shiny tools and it's hard not to play with them. It's like LEGO for programmers.

And hey, when you can push the boundaries of abstractions and keep things fast? It feels like you've cracked the code to the universe.

But still; most people just want to see what the code does, not spelunk through an art installation of traits.

The core problem is that Rust being Rust turns code you can’t understand into the default. The community shows up to tell you that if you don’t over-complicate it, you’re writing unidiomatic Rust.

If "Go to Definition" can’t take me to your implementation and I have to dig through your GitHub repo just to see how Matrix4::mul works – can I really say I know the code I’m using?

For many people, maybe that’s fine. But every dependency you bring in is still your responsibility. Obviously I don’t understand every library I use – that’d be absurd – but I’d like to live in a world where I can understand the code I bring in.

And just to be clear: abstraction isn’t the enemy. It’s what lets you write 3D engines or HTTP servers without caring about hardware or the TCP stack. The problem is when we build for someday instead of today.

I’m not saying stop writing clever code – just make sure it earns its keep. When you feel that "maybe I should make this generic" impulse, ask: Who benefits from this, today? If the answer is "future me," maybe wait until future you actually shows up.

Here’s my rule of thumb: keep "Go to Definition" useful.

The Conclusion

I've been on both sides of the extreme. Heck, my first time trying to learn OpenGL I tried to write a compile-time zero-cost abstraction for it while I was learning it. Later, I just went with raw OpenGL in a dozen different projects. So, yeah, I've lived both sides of the story.

From that experience, I've learned one thing: things are almost always easier when there are fewer moving parts. Simpler code doesn't mean worse code – it just means you can still understand it six months later.

So maybe try the other side of the spectrum if you haven't. Or don't.

Anyway, this post will probably age terribly. Someone will send it to me in two years while I’m working on my eighth trait-based ECS library written entirely in macros.

But for now, I just wanted to encourage maybe one person to try to write code that's just code... not abstracted, not filled with traits or generics... just code.

Maybe one day the novelty will wear off, and Rust will chill out.

Until then, I'll be over here using glam.

If you enjoyed this post, I'd love it if you could whisper 'nice post' at your screen... or drop me a coffee.
Or join the discord, tell me what you think.

P.S grammarly forked me over vro 🥀

Godot Ruined My Sense of Speed

2025-10-12T21:09:01.870614127+00:00

Godot didn’t just ruin my game. It ruined how I think about performance and abstraction. What started as a simple voxel prototype spiraled into an existential crisis

It was a sunny day (probably), a few months back. I was in a hotel room on my laptop – the one I definitely bought for studying – playing Factorio, like any good student does. And then I had a brilliant idea. An automation game. Factorio, but bigger! And better!

Did it matter that I had no experience making games? Don't be ridiculous, of course not!

The plan: mix Factorio’s automation, Terraria’s boss fights, and a Minecraft-esque voxel world. So I said, considering I have no graphics development experience I should start simple – and make a voxel engine

The Prototype

All good games need a prototype
- Sun Tzu

Naturally, the next step was to pick an engine.
I wanted something fast, simple, cross-platform – and preferably not Unity, because, well, Unity.

Godot seemed perfect. Lightweight, open source, recently got a shiny new 3D renderer (and also because UE hates MacOS)

Of course, I knew GDScript wasn't going to survive a voxel world. So I wrote the simulation in Rust and used Godot purely for visuals.
Simple plan, what could possibly go wrong?

So I started.
Made a Rust extension. Drew a quad. Then a cube. Then a whole chunk.
Suddenly I had mining. Machines. Inserters. Belts. Quarries. Crafting.

I was unstoppable running purely on caffeine and motivation.
It might sound like I'm glossing over the implementation, but the entire prototype took literally two days.

I had so many conversations about how the quarry should work with my friends. It was an interesting design problem: finding upgrades for quarries that weren't just "the same thing, but faster", especially since the quarries were meant to dig into the world and destroy it.

That also turned quarries into a single-pipe problem — where common resources clog the system and starve rarer ones. Totally irrelevant for this prototype though, since items were just physics bodies moving on top of belts.

Anyways, I was ready. I had spent roughly 32 hours over 2 days working on the first prototype of my life. I went outside to grab some food, came back, and even arranged a play-test for the next day.

Everything was perfect.
The engine worked. The game ran smoothly – until it didn't.

Things go VERY WRONG

Look, I'm lucky enough to have a great computer. During my testing I couldn't even get the game to go below 144FPS.
But see, I never tried throwing more quarries at it because I assumed any slow-down would come from the naturally expensive thing – the rigidbodies that I used for items.

In order for this to make sense I need to show you how procedurally generating a chunk goes in Godot.

A chunk is just a mesh made of triangles made of vertices. In the simplest voxel engines, you’d generate a quad for every block face — slow, but simple. For the prototype, I added a very naive culling algorithm so it wouldn’t generate hidden faces.

So far so good. This entire algorithm was implemented in Rust (blazing fast!).

Godot exposes a type called SurfaceTool, which isn't technically the lowest-level API they provide but it is pretty much a drop-in replacement for pushing individual vertices into a list.

Anyway, here’s how that looked in code – calling into Godot from Rust, in order to draw a quad:

fn draw_quad(st: &mut SurfaceTool, k: &mut i32, quad: Quad) {
    let normal = match quad.direction {
        ...
    };

    st.set_color(quad.color);
    st.set_normal(normal);
    for corner in quad.corners {
        st.add_vertex(corner);
    }


    st.add_index(*k);
    st.add_index(*k + 1);
    st.add_index(*k + 2);
    st.add_index(*k + 2);
    st.add_index(*k + 3);
    st.add_index(*k);

    *k += 4;
}

And here’s what “just pushing to a list” looks like in comparison:

fn draw_quad(vertices: &mut Vec<Vector3>, indices: &mut Vec<i32>, k: &mut i32, quad: Quad) {
    let normal = match quad.direction {
        ...
    };

    for corner in quad.corners {
        vertices.push(corner);
    }


    indices.push(*k);
    indices.push(*k + 1);
    indices.push(*k + 2);
    indices.push(*k + 2);
    indices.push(*k + 3);
    indices.push(*k);

    *k += 4;
}

You might notice there’s not much difference, so really, how bad could SurfaceTool be?

8 milliseconds per chunk! Not terrible – until you realize doing it manually takes 300 microseconds. Twenty-seven times faster.

And that’s not even counting Godot’s mesh conversion time, which I’m pretty sure happens way later.

At this point you can probably guess what went wrong. When my friend play-tested the game, the framerate dropped to a cinematic 10 FPS within an hour.

Why didn't I notice it during my own testing? Simple, I was doing things efficiently. I already knew what to build, nothing went to waste.
He, on the other hand, decided to cover the planet in quarries (like, five quarries).

After it dropped to 10 FPS, he stopped playing. Which, fair.
I still count an hour-long playtest as a win – but the reason he stopped playing was... traumatizing.

The Rebound

The prototype was a success, somewhat.
So now it was time to make the actual game, properly this time.

After that Godot fiasco I decided I'd just go pure Rust.

But you can't just start a project, you need an engine! And it needs to be super performant because I never want to see someone stop playing because of performance again.

Okay, calm down champ.

After the Godot incident (yes, I'm going to call it that, fight me) I over-corrected hard in the other direction to the point where I was seriously considering making a full-blown game engine.
Which, granted, isn't entirely out of the question for me... but still, absurdly unnecessary.

Eventually, a brick hit my head and I realized I could just... make a game. No engine. No framework. Just raw OpenGL and a giant while loop.

Of course you don't need fancy frameworks or giant game engines... You can just make a game.

At the time, however, this was a big revelation for me.

So I opened up LearnOpenGL and started replicating my Godot voxel engine one-to-one. Which was quite easy, considering I had to do everything manually anyway.
I had a pretty good voxel engine by this point, it was so much faster than Godot could've ever been, but now I had to actually implement game features.

The first of many being machines.

You see in games like Factorio many machines don't need to always run. In fact, they don't! Most machines take in some sort of input, process it for N frames, and then do something as a result of it.
This sort of system lands itself very well to a WorkQueue.

Basically, whenever a machine needed to do something again in 20 ticks it would tell the WorkQueue "hmu in 20 ticks" and then the WorkQueue would handle that accordingly.
This system made sure that even if you had millions of machines only the ones that needed to be updated this tick would be accessed.

Then, came the belts. In Godot I used physics bodies for items on belts because that was the easiest way to do so but it came with a lot of cons the biggest of which being the fact that belts had no throughput limit. Which cuts out basically 80% of the puzzle in automation games.

The tricky part about Factorio-style belts is that they need to be updated back to front, so I had to figure out which belts depend on which other belts – a mini dependency graph!
Now, after coming from Godot my perception of performance was so ruined that I was incredibly worried that this was going to be a major performance bottleneck if I didn't aggressively cache it.

Luckily for me, I am not skilled enough to be able to write an algorithm that's able to heavily cache it so I decided to settle for just reconstructing the entire graph every frame. And guess what? It never became a performance problem.

Well that was simple enough, I'll also mention the things that happened after all of that.
I went on a 3 week journey to optimize the heck out of the voxel engine, during which I switched from OpenGL to WGPU because OpenGL on MacOS does not support Shader Storage Buffer Objects (SSBOs)

I might make a post on how I optimized the voxel engine (check out this video by Vercidium) but by the end of it I had a voxel engine with async chunk & mesh generation, running at 144FPS+ on an M2 MacBook using 3 GB of ram with a render distance of 3072 blocks in every direction.

The conclusion?

I can't say this story has a very good conclusion because the game never ended up getting finished. Mostly because I couldn't figure out a way to make a factory game feel nice to play in a 3D voxel sandbox.

What I learned from all this wasn’t really about Godot or performance – it was about trust. Or the lack of it.

I thought I was writing about slow code, but looking back, I was really writing about black boxes I couldn’t see inside.

After going cold-turkey on abstractions, I realized something worse than inefficiency: bloat. It turns out working in a simple, honest codebase – one where you see everything – is just more fun.

For those who may want to check out the source code for the final version of the game here you go

Maybe there's a conclusion to draw from this story, in any case I hope you enjoyed it. And if you did, consider buying me a cup of coffee

Four years, Five failures, One compiler

2025-10-05T14:36:34.509273115+00:00

At 14, I thought writing a compiler would be a quick side quest in building a game engine. Four years later, I finally built one that works. And it was one hell of a journey.

Before I dive into the compilers themselves, I should explain why I even started making them in the first place. Initially, writing a programming language wasn't the goal; it was just supposed to be a small part of a bigger piece: building my own game engine. I didn't expect that "small part" to turn into a four-year rabbit hole, but now that you know why it all started, let's look at a few of the failed projects, shall we?

CryScript

Super edgy name, I know. To be fair, the game engine this was meant for was called Crytex, so that doesn't make it any better. It was back in early 2022, so technically, the title of this post is clickbait. Oh well.

While writing this, I dug through the old GitHub repo, which had a very odd structure. Something like this:

crates/
 cry_script/
 src/
        ..
    Cargo.toml
src/
 main.rs
Cargo.toml

I have no idea what I was on when I set it up like that, but for a moment, it actually scared me. I thought I'd lost the source. Luckily, the code's all still there, so let's take a look and have some fun.

I'm pretty sure I started off by following a Python compiler tutorial... in Rust.

And surprisingly, that worked well for the first half. I got the lexer and parser running (basically the parts that read the code), and they still hold up well even now.

However, things started falling apart once I reached the interpreter, the bit that's supposed to run the code.

But up until that point? Honestly, not bad. Even skimming through it today, I can see the same patterns I still use in my work.

..Oh my god, I take all of that back.
The interpreter is an abomination of Rust code, and it's also where you can clearly see the effects of Python. It's a tree-walk interpreter, which basically means the Rust compiler absolutely hates it.

I vividly remember fighting the borrow checker & sprinkling in `Rc<RefCell<_>>'s everywhere whilst writing this, and it seems like eventually, I just gave up and resorted to doing:

struct VariableReference {
 reference: *mut Variable,
}

Which is, apparently, a non-clone, manual version of a reference-counted value?
Not a clue who wrote that code; definitely wasn't me!
For non-Rust users: this is me fighting the language's safety system and losing badly.

I have no idea where this was needed, but it might be one of the worst pieces of Rust code I've ever written, second only to the Crytex engine.

That one doesn't even compile anymore, by the way, because newer Rust versions prevent casting an immutable reference to a mutable one. (Which, fun fact, is undefined behaviour)

Oh, and apparently, I was passing around the main context of the interpreter as a mutable pointer. Those of you who use languages like C or C++ might think "so what? that's normal", but in Rust, using pointers mixed with references comes with quite a bit more headache.

In hindsight, CryScript was less of a compiler and more of a Rust safety demonstration. The fact that it even ran code at all is a miracle. If I pulled this at a Rust conference, I'd probably get banned. But it was a Rust newbie's first attempt at making a compiler, and it wasn't a half-bad one.

azurite

Fast forward a year, and I started making azurite (the 'a' is non-capitalised intentionally). This one's very near and dear to my heart as it's the project that let me meet some amazing people I still talk to today.

Unlike CryScript, this one came a bit later, when I actually knew how to use GitHub. It has 76 commits, many of which have completely nonsensical names that could probably get me rejected from a few jobs.

I should, however, mention that between starting azurite and finishing CryScript, I joined the r/ProgrammingLanguage's Discord server, which led to me reading the book Crafting Interpreters. I think everyone interested in compilers or interpreters should go through it at least once.

Unfortunately, I don't actually know when azurite started, since the GitHub repo seems to have been created after the language was already up and running. There are a bunch of example programs and documentation in there, so it must've been pretty far along.

There are binaries uploaded from the early days, but since I apparently thought my code was too special to share, I didn't upload the source, you know, in case someone stole my brainchild. After a while, though, I came to my senses, uploaded the code, and blessed the world with my amazing engineering.

A significant difference between azurite and CryScript is that azurite actually had static analysis, whereas CryScript was dynamically-typed. That said, the lexer and the parser are almost identical.

I'd love to make fun of the static analysis, but honestly, many of the core ideas I used back then are still part of how I think about language design today. It's surprising to see that, at least on a high level, I already had a so-so grasp of the basics.

But I did find this comment, which I think perfectly captures my ambition at the time.

// TODO: Maybe make the multi-file-loading multi-threaded

The bytecode interpreter for azurite had a major performance flaw that someone else figured out. If I remember correctly, it was something like this:

let mut callstack = ..
let mut code = &mut callstack[0];

let mut code = callstack[0].clone();

That one change made the interpreter run 10x faster. Wild. But more importantly, that flaw introduced me to leddoo, who's now a close friend. So I guess being bad at programming has its perks.

I also noticed other people starring and contributing to this project, which might make you wonder why I stopped working on it. The reason is quite simple really, the codebase collapsed under its own weight.

See, that's the problem with making a long-term project in a field you barely understand. Every time you add something that wasn't initially expected, in my case that was generics, the codebase just gets worse and worse and eventually it got too much to handle.

It's bittersweet reading the old commit log. People added features like a REPL — that one was my now-friend Pyrotek45 — and then months later, I removed it. To anyone who ever contributed to azurite and happens to read this: thank you. I really mean it.

margarine

And now the final gauntlet. margarine.
I started near the end of 2023. At first, it was supposed to be for another game engine, this one called butter. The plan was to make a language centred around ECS architecture and value types. I even wrote a lexer, parser, semantic analysis, and an LLVM-based codegen.

But when it came to integrating it, I caved and just used Lua. Yeah. Because here's the truth: I'd spent four years learning how to make a compiler... but not how to make a game engine.

That actually felt horrible. After all that work, I shelved margarine. I moved on to voxel engines, games, raytracers, fluid simulations and much more..

You read the title, though, you know the story didn't end there.

A couple of weeks ago, I came back to margarine, for what reason I don't know. This time, I stripped away the over-engineering (no more ECS gimmick). I ditched LLVM (way too painful) and built a clean bytecode interpreter instead.

And now? I finally have what I dreamed of: an embeddable programming language I can use in any project.

So here it is, after years of broken interpreters, pointer hacks, and abandoned repos, I am delighted to introduce to you, margarine:

fn main() {
 var numbers = [1, 2, 3, 4, 5]
 var multiplier = int::parse(std::read()!)!

 var doubled = numbers.map(|n| n * multiplier)
    print(doubled)
    // If input is 2 → [2, 4, 6, 8, 10]
}

A language that feels like Rust, but without the fights I used to lose with the borrow checker. It's a statically-typed language that is almost too trivial to embed into any project. The syntax is very akin to Rust with Iterators, Closures, and much more!

Was this post just a big ad for margarine? It certainly wasn't the intention but after four years it feels good to finally share something that works, and it couldn't hurt to check it out can it?

and hey, if it resonated with you consider dropping me a coffee

hello world

2025-10-02T19:36:48.068611622+00:00

uh, hi, idk what to say here but helloooo. i made a static site generator for this.
it takes the first line of the markdown as the title and the 2nd line as the summary
actually i lied you can use multiple lines if you end the line with a \

um, i'm gonna ask chatgpt to write something here
it generated something super corny as expected. i ain't putting that in here