captainhorst

The site uses CSS nesting which requires a browser with baseline 2023 support.

The map data is provided in the USD format which is a 3D authoring and interchange format that can be used with a lot of software. Unlike the final optimized data used by the game this doesn't require revere engineering and can be seen as source data that is in fact useful for graphics researchers and game developers.

There's also https://womp.com as an SDF modeler

I use Zig for all my hobby projects:

- A pixel art editor https://github.com/fabioarnold/MiniPixel

- A Mega Man clone https://github.com/fabioarnold/zeroman

- Zig Gorillas https://github.com/fabioarnold/zig-gorillas

And most recently I had the opportunity to build a visualization for TigerBeetle's database simulator: https://sim.tigerbeetle.com

Before I was using C++ and Zig has been an improvement in every way.

Their biggest release in terms of issues closed: https://github.com/ziglang/zig/milestones?state=closed 1012 in less than 8 months. What an amazing feat.

Sorry, totally missed your reply! At first we had normal text and then we switched them for hand-drawn sprites. The text animation consists of 2D transformations (translation, rotation, scale) interpolated over time. It's all animated in code. NanoVG helps by having a transformation stack like OpenGL. In Zig I can open a block like this:

{ vg.save(); defer vg.restore(); // undo all transformations at the end of the block

  vg.translate(...);
  vg.rotate(...);
  vg.scale(...);
  // draw sprite

} // continue to draw the rest of the scene

We use NanoVG: https://github.com/fabioarnold/nanovg-zig

I used my Zig port of NanoVG: https://github.com/fabioarnold/nanovg-zig which ultimately uses WebGL for rendering in the browser.

There are tools in the upper right corner. You can pick one and use it on a beetle. ;) This introduces various faults in the simulation that the database has to recover from.

Minor spoiler: there's another tiny game hidden at the end of the third level.

Interesting tool. But looking at the code when you load a video it simply decodes all frames into memory. If you deal with 1080p footage at 30 fps you will hit 4 GB with just ~23 seconds of video.

Sadly, videos can't be larger than that. For one there's a memory limit per browser tab. Secondly, wasm32 is not able to address more than 4 GB of memory.

Editing feature length movies is certainly out of scope for this editor. It's meant for editing short 10-30 second video clips that are well within the limits of 2 GB. We keep compressed video in memory and only deal with a few decompressed frames at a time.

We avoid H264 patents by not shipping an H264 encoder/decoder. We leverage the browser's WebCodecs API which in turn uses the platform's native codec API. It's the OS and the hardware vendors that license H264 patents because they're the ones providing the H264 implementation.