Paavo Huhtala

I've been reverse engineering & decompiling Worms: Armageddon (into Rust!) for the past 3 weeks. So far I've replaced about a 120 functions and made a lot of tools, but I'd like to turn this into an OpenTTD/RCT style project soon-ish, with multiplat support as a very long term goal.

Fair warning: this codebase is easily the unsafest Rust codebase I've ever seen. Rust<->C++ FFI isn't nice at the best of times, and it's much worse when you don't have access to the other side's source code, that side being 90s C++ with no memory safety features but multiple inheritance aplenty.

I've been reverse engineering & decompiling Worms: Armageddon (into Rust!) for the past 3 weeks. So far I've replaced about a 120 functions and made a lot of tools, but I'd like to turn this into an OpenTTD/RCT style project soon-ish, with multiplat support as a very long term goal.

A large part of this has been accomplished using Claude Code & GhidraMCP. I like reverse engineering, but I don't particularly enjoy reading decompiler output or figuring out calling conventions from disassembly. Turns out LLMs are really, really good at that kind of pattern recognition.

One thing I've learned while writing a voxel engine is how huge the difference between "realistic" and "worst case" can be. With the same render distance, a typical hilly landscape uses about 2MB of VRAM, while a 3D checkerboard pattern uses over a gigabyte. Yup, that's three orders of magnitude!

I'm using the checkerboard pattern as a stress test, and it's quite good at that. It breaks most optimizations in my engine, namely empty / occluded chunk optimization and greedy meshing / face merging. Every chunk has the max amount of faces, giving the mesh generator a good workout.

There comes a time in every developer's life where they just have to write a voxel engine. This one is using #rust, wgpu and GPU driven rendering. #graphicsprogramming

Progress about 24 hours later

I'm working on a new article, and it's once again grown to be an absolute monster in terms of length. I've had a 49 inch 32:9 monitor for about 3 years, and I want to tell the world how's it been. At the moment I've written almost 10 thousand words about hardware, productivity use and gaming.

This is actually my third attempt at writing this article; in the first two iterations I had written several thousand words before even getting to the part where I buy this monitor. This time I handled that in a few paragraphs, and could mostly focus on the actual topic of the article.

I've continued working on my little 3D engine based on wgpu and #rustlang. This week I managed to implement fully GPU driven rendering. The engine gives the GPU lists of drawables and meshes, and compute shaders perform AABB culling and generate indexed draw commands. 17K objects in about 0.03ms.

The main benefit was performance. While release mode was fine, in debug mode (which I want to use to get wgpu validations) my little test scene was struggling to reach 60 FPS on my very powerful PC. Now it sits comfortably at locked 240 FPS, and release builds run at about 1000 FPS.

I'm working on a shader playground / 3D engine skeleton in #rustlang with winit, wgpu and naga_oil. About 1.5k LOC, has shader hot reload and very basic GLTF support. The DX is better than in my previous WebGL-based engine but the ecosystem is not yet very mature / stable.

wgsl-analyzer provides autocompletion & syntax highlighting for VS Code, but doesn't support the same import syntax as naga_oil (even though it has some Bevy-specific features [which will be removed because of WESL migration?]) So I have to live with non-actionable errors in my IDE.

I'm working on a shader playground / 3D engine skeleton in #rustlang with winit, wgpu and naga_oil. About 1.5k LOC, has shader hot reload and very basic GLTF support. The DX is better than in my previous WebGL-based engine but the ecosystem is not yet very mature / stable.

I started this in December and resurrected it a few days ago by updating my dependencies, which took about an hour because of breaking changes in winit and wgpu. Good that these libraries are actively developed, but I imagine building anything bigger on top of these can be somewhat painful.