If you're not familiar, we take an opportunity each month to highlight some of the amazing work that's being shared on the Discord server and share it with the broader community as well. We also get a few words from each project's creator so you can learn more about what they're up to.
We've got a big one today, so let's get into it!
Palanteer (by Dadaaam)
This project came out of nowhere this month. Palanteer is a comprehensive profiler for C++ and Python with many useful ways of viewing all kinds of performance data. It's a super exciting project, and the author has gone to great lengths already to make it ready for use.
Here's a little background to entice you.
I started this project 1.5 years ago, as a side project "just to relax" at home (boring job and 3 small and active kids...). Also, visual projects are funnier than embedded software, which is my main work.
The streams of Casey and Jonathan resonate when they encourage "handmade" code. I indeed learned a lot on this project, from coding on Windows (I am used to Linux), what is really Unicode (and how Windows solved it with the double A & W API instead of UTF-8), how to load GL extensions, all the X11 fun, ptrace for context switches, macro fun and their compatibility on main compilers, ...
It took so long before reaching an acceptable quality for several reasons:
- when a project is private, full freedom is preserved: breaking compatibility, changing deeply base principles...
- good usability and easy interfaces takes time and iterations. Most part were rewritten several times before their actual state. And it is probably not finished.
- it started with having in mind the RAD telemetry demo than Jonathan Blow made in one of his stream, in order to profile another pet project.
And quickly, it got enriched with a lot of features that I would have liked to have for my past projects (tracking data, memory, context switch, locks..., be able to graph all of them under different forms) and in a context which would solve the typical problems when instrumenting (emphasis on compile time work especially for strings, be able to enable instrumentation per group at compile time) or developing (assertions, stack trace...). At the end, be able to reuse the instrumentation to build tests was the last brick to solve the now general goal of the tool: "improve software quality".
I cannot say that the project "pivoted" because it followed its track without really turning, the goal just broadened with time.
In its actual form, the tool (profiler, viewer, scripting module) is fully functional. It needs testers to get better, find bugs thanks to different stimulation, get feedbacks on how to smooth it (details matter...) and improve it little by little.
Mu (by Kartik Agaram)
Mu is a project that consistently fascinates me. Kartik has a really unique outlook on computing and his work shows off an entirely different side of the Handmade ethos.
Kartik shared this info about the project this month:
The Mu project is about making software accountable to the people it affects. Today nobody understands the big picture of what goes on inside our computers. We started out with abstractions we could drill into the details of, but over time have ended up with abstractions we never want to look inside. I want to go back to the old meaning of "abstraction," a computer that exposes its insides to curious observers on their own schedule, and stimulates curiosity by helping them to answer questions about it for themselves.
Over the last month I've wrapped up the core skeleton of the computer: a relatively user-friendly, high-level and safe language built out of a low-level and safe language, which in turn is built out of a low-level and unsafe notation for bare x86 machine code without an OS. The top-most level is interpreted and slow. Speeding it up is a non-goal; it's intended to be for prototyping, and designed to nudge people to reimplement programs one level down once they decide what they want. I hope that way to avoid the tower of Babel in mainstream software, with languages piled ever higher on other languages without regard to comprehension and runtime cost.
I'm undecided on where to take it next. I might try to build a mouse or network driver. Or get it running on native hardware. Both are far out of my comfort zone, and I'd love to get help on them. Another recent idea is an offline reader for http://internet-in-a-box.org/.
Kartik frequently uploads short videos demonstrating different aspects of Mu. I find them really inspiring, and full of interesting ideas about new ways of interacting with computers. I recommend checking them out, and checking out his website.
Game Engine Series
For quite a long time now, a user by the name of Game Engine Series has been uploading a line of educational videos named...well, Game Engine Series. These videos take you through the process of creating a game engine from scratch, and there's quite a lot of material to dig into!
As a hobby, I've always wanted to make games and 15 years ago I really started studying what it takes to make a game. I'm not sure if commercial game engines were a thing back then, but the idea of using one to make a game didn't really cross my mind since I really wanted to know all the nuts and bolts that hold a game together. So, I started writing a "game" which was basically a render engine. That's when I started realizing that a game engine is much more than a graphics renderer, and that I actually liked the engine part more than creating the game. Since then I've been just writing game engines that are incrementally better than the previous ones. It's been a real learning journey that's still going on, which also benefitted my professional career as a software developer, simply because of the fact that as a game engine programmer I get to tackle almost all challenges in computer science.
After a while (and a lot of googling stuff, studying open-source game engines and going through StackOverflow), I thought it would be a cool idea to share everything I'd learned with others who're also interested in games and game engines. That's why I decided to make a video series that I'd have appreciated watching when I was starting to write my first engine, and that's how, about a year ago, The Game Engine Programming Series was born. 🙂
Instead of starting with a renderer right away, I decided to take my time and set up the infrastructure and the architecture of the engine and it took me almost a year to get to the point that I found would be a good time to start writing the renderer. This has been the subject of last months videos.
SlimApp & SlimEngine (by HardcoreCodin / Arnon)
It's no surprise to see great work from HardcoreCodin in #project-showcase, but this month he has been absolutely prolific. He released two projects in conjunction: SlimApp, a minimal platform layer for graphical applications, and SlimEngine, which extends SlimApp with 3D features. Both are tiny and result in tiny, efficient executables. Since the release this month, he's added all kinds of useful features without compromising the vision of the projects.
The project(s) drew inspiration from HMH, RayLib and olc::PixelGameEngine. I wanted something more minimal and hopefully simpler to get started with. That means no-brainer setup for both C and C++ with the same codebase and no dependencies.
By comparison, HMH does a ton right but was never meant to be 'minimalist' or reusable/customizable. olc::PixelGameEngine is C++ and uses OpenGL (also the API is not as simple as I would like). RayLib has simple C interface, but is C99 (so needs wrappers for C++) and uses OpenGL. It is also not very minimal - it has a lot of features built-in - so is more of a software stack.
So then, SlimApp is a platform-agnostic application/platform layer(s) for windowed application development. SlimEngine is just SlimApp extended with facilities for interactive 2D/3D application development.
Both come with example apps demonstrating their features with a heavily documented README. Both are available as either a single header file or a directory of headers (a "unity build" setup).
Both can be compiled as-is in either C or C++ with no dependencies (not even OpenGL). SlimApp doesn't use anything from any standard library. SlimEngine only uses the standard math header ('math.h'/'cmath.h') for sqrt(), pow() etc.
Bare-bone executables (on Windows) are ~13KB for SlimApp and ~17KB for SlimEngine.
And much more!
There were tons more projects this month that were worth showing off, but we really just don't have enough room here to dig into them all in detail. We'll share more about them in the coming weeks.
It's exciting to have so much to share - thanks for being such an amazing community!