End-of-Year Recap

I’ve been working on Orca for almost a full year, and since 2023 is wrapping up it’s as good a time as ever to do a recap of what happened!

Starting Off

After finishing my PhD in January, I knew I didn’t want to pursue a career in academia, but didn’t want to knock at the door of big corps either. I wanted to continue doing research and programming by other means, though. I also had this idea of a new application development and distribution platform using WebAssembly, which I had played with for my 2022 Wheel Reinvention Jam entry. This jam project had drawn some interest from the Handmade Network admin team, and as we were discussing how to make it into a real thing, I figured I should just give it a go and try working full time on it.

The goals for this first year were to refine the vision and lay out a plan for the project, and bring the codebase to a point where community members could try it out and start contributing.

I began by repurposing a platform layer I had developed called Milepost, which I used in previous projects like Audio Testbed, the original Orca Jam project, and Quadrant. I streamlined the windowing layer and event loop, rearchitected the UI layer to have a more flexible layout and styling system (you can read about that here), introduced a packet-based file IO API, and started porting the codebase to Windows. I also started improving my vector graphics backend, and ended up switching to a completely different method, based on Nehab and Hoppe lattice-clipping algorithm (that’s a deep rabbithole in its own right, and I should really write about the method I’m using soon). At the end of June I had just enough to build and run a simple example game on both macOS and Windows.

Public Announcement and New Contributors

Around that time I was joined by Ben Visness. We set up the Orca website, and published the first announcement of the project in June. Following this post we welcomed Ilia Demianenko and Reuben Dunnington to the team.

Ben put together our initial C standard library shim to compile stb_image and stb_ttf to WebAssembly. This allowed moving the image and font loading code to the WebAssembly side, making it sandboxed and reducing the complexity of the runtime. Ben then wrote the first iteration of the build tools in Python. This was a big improvement compared to the previous build process, even if Python proved to not be up to the job later on (see below!)

Ilia worked on the UI styling and the default widgets. Ilia has a neat design eye and great attention to detail, and it shows in what he did with the UI. Not only did he make the base themes and styles look really nice, but he went on to tweak and polish a lot of the widgets behaviors to make sure they follow consistent interaction patterns and established UI conventions.

Reuben finished porting the platform layer to Windows, and fixed an impressive number of issues on both Windows and macOS along the way. He also contributed to improve our WebAssembly bindings generator, and helped testing and debugging the build tools. Finally, Reuben has written his own WebAssembly runtime in Zig, called Bytebox, which will be extremely handy in the near future (see below).

Opening the codebase, and the 2023 Wheel Reinvention Jam

We open-sourced Orca in September, the week before the 2023 Wheel Reinvention Jam. I’ve covered the feedback we received following the opening of the codebase and the jam here, but let’s sum it up here.

The build story proved to be a big hassle for users, generally due to toolchain configuration mismatches. In particular we realized there can be huge discrepancies and incompatibilities between different Python configurations, which we don’t have control over. It prompted us to completely rethink the user workflow and tooling (see below).

Other than that, we were pretty pleased with the feedback of users who did get through the build process. They seemed to like the APIs and were able to work inside the constraints of the MVP to make small applications without much trouble. Some were even able to dig into the codebase on their own to add features they needed, and contributed patches. (Many thanks!)

The project also sparked interest from our friends in the Zig community, and Loris Cro, Andrew Kelly and Jonathan Marler did a couple streams where they worked on a Zig build script for Orca, which was pretty cool to see.

Handmade Seattle

In November Orca was featured at Handmade Seattle. I’ve attended all Handmade Seattle conferences since 2019, and it’s always been a hugely motivating highlight of the year, listening to insightful talks and connecting with like-minded programmers. So I was delighted to also have something to show fellow attendees this year. We had a demo video followed by a live Q&A, as well as a booth in the demo hall, where Reuben and I showcased Orca, answered questions, and received feedback from a lot of sharp folks.

Handmade Seattle was also the perfect opportunity to meet up with the Orca core team in person, and discuss future plans!

What’s Next

Talking about future plans, here’s what’s in store for the beginning of next year:

C standard Library

We already already started putting together a more complete C standard library based on musl instead of the current minimal “shim”. Although we’ll strongly encourage using Orca’s own APIs to interact with the platform, it should smooth out onboarding for C developers, and make it easier to compile existing C libraries to Orca.

This will still be a subset of the C standard lib, because we’re dropping some things that don’t make sense in the context of Orca (or that don’t make much sense period!) like locales, signals, and environment variables. But all “freestanding” APIs like strings, maths, conversion functions, etc. are in there. We also provide memory allocation and process control functions that will call into the appropriate Orca APIs. Standard IO will forward to our own file API using the app’s private data root.

D3D Vector Graphics Backend

When I ported the vector graphics backend from Metal on Windows, I chose to use OpenGL, mostly out of familiarity with the API and shading language, and also because I thought it would give us easier access to more platforms later.

In hindsight this proved to be a big mistake. OpenGL is far from being actually portable, and each driver has its own sets of quirks, bugs, and slow paths, especially on Windows. Unless you don’t do anything fancy, it makes it basically impossible to develop, test, and debug with confidence because each machine can potentially have its own glitches and performance problems. Playing this whack-a-mole game isn’t entertaining, and there’s just too many possible configurations on Windows platforms.

So I’ll just have to bite the bullet and write a D3D backend. Besides, there are other reasons we need to introduce D3D at some point. OpenGL gives little control over surface presentation and compositing, which means we have to hack our way around it to combine the apps graphics surfaces and the runtime debug overlay, and control the frame pacing of the app.

Tooling

Ben has started working on a native tool to streamline the Orca apps development workflow.

• orca update [--install-dir dir] downloads and install the latest versions of the tool, binaries and SDK in the install dir.
• orca sdk-path [--version version] prints the path of the SDK (so that people can add the include/lib paths to their build commands).
• orca bundle [--version version] [--target platform] [--resource-dir dir] [--resource file] [--icon icon] --name name module.wasm bundles a wasm module and resources into an application. This will support cross-bundling, e.g. creating a macOS app bundle on a Windows machine.

The runtime binaries and wasm blobs needed to create an Orca app will be built in CI and downloaded by the tool, so there won’t be a need for app developers to build the runtime from scratch anymore. The notable absence of Python will also allow us to dodge a load of issues we had with the first MVP.

Custom Wasm Runtime and Debugging

As I mentioned above, Reuben has experience writing his own WebAssembly runtime. We’ll be working together to move off wasm3 and develop Orca’s own Wasm engine, which will afford us more control and allow us to provide a really good integrated debugging experience.

I can’t pull this off without your support

I’ve been working full-time on Orca for almost a year! It feels great to fully dedicate my time to steer and work on a project I truly believe has value. It has also allowed moving forward way faster than we would have if I were doing this as a free-time project. In fact, the project probably wouldn’t have gone anywhere otherwise.

However, it has not been gentle on my savings. It is obviously not sustainable at this point. Starting January, I’ll be taking a 6 months long, 2 days a week research contract for a cognitive science project. This should help a little bit with the groceries, and the topic is pretty cool as well: in short, I’ll be doing signal processing to test theories of speech comprehension.

This still leaves the best part of the week for Orca, and more than ever, I intend to make it my main, financially viable job. In fact, reaching a situation where I can dedicate most of my time to Orca without going broke is one of this coming year’s goals.

And that’s where you come in. Without support from community members, I can’t pull this off. So if you feel like what we’re doing with Orca is important and could bring a better future for both application developers and users, I’d really appreciate if you chip in through our Github Sponsor page or via our Donorbox form. However small, one-time or monthly, your contribution can make a huge difference and give Orca a chance.

Happy end of year,

Martin