For the past few months, Asaf and I have been working hard on rewriting the Handmade Network website - and as of today, we're pleased to announce that it is live, and you're using it right now!
The new site has been written from the ground-up in Go, replacing the old Python / Django codebase. The whole site should immediately feel snappier and more pleasant to use, but we've tried hard to keep all the features you know and love from the old site.
It's not all the same though. Here's one big new addition that we hope you'll like...
The old BBCode-based editor has been completely replaced with a new Markdown-based editor. It features real-time previews and all the features you'd expect from a Markdown editor, including GFM extensions and some features from Discord (like ||spoiler tags|| - always a favorite!).
However, if you are for some reason a BBCode diehard, that is still supported. You can freely mix BBCode and Markdown, and everything should just work.
In the near future, we're planning to add image uploads, so you can directly paste images into your posts without hosting them elsewhere. This has been a long-requested feature, and with this new codebase we're finally in a good place to tackle it.
With the new site released, we're in the perfect place to start working on lots of new features. Here's a few of the things we have coming up:
You may also notice that a couple features from the old site are in fact missing - the library, and the wiki.
The library will be ported soon, but had to be temporarily cut in order to make some of our other deadlines. When the library comes back, it will be better than ever, with new features that let you save your favorite articles for easy access later.
The wiki, on the other hand, is gone for good - but all the wonderful wiki content written by our community will have a new home. We're still working out the details, but rest assured that it will be back soon.
We really hope you like the new site. It feels great to get this project out into the world, and we're eager to hear what you think about it. If you have any feedback, feel free to leave it as comments on this post, or create new threads in the Site Feedback forum.
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.
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/.
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.
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.
For C3, generic modules and parallelized codegen were the focus of the last month or so.
Final code generation is now done on multiple threads by default on Linux and MacOS.
Most of the coding was refactorings to enable the generic modules.
I think the most work was doing those refactorings and once I had everything set up for the generic modules it was pretty easy. It required implementing function name and constant name aliases.
This was probably the biggest feature I had left to do for C3 as well. I have things left to implement, but nothing this size.
As a side project, I am making a roguelike, working title "Dungeons". It's an avenue for me to explore with gameplay programming in a straight forward way, with a lot of freedom in gameplay exploration. It is a 0 dependencies project, entirely from scratch, using software rendering for graphics, written in C-like C++. I am architecting the platform layer to be reusable for my future projects, and I'm already putting it to work to also make my own handmade text editor!
Frustrated with the lack of interconnection between CAD environments and spreadsheets in existing software (I work in BIM / structural engineering) I decided to make my own software and connect those two elements into one program.
CAD elements properties can be accessed and manipulated in the spreadsheet. Manipulating CAD elements in the CAD view recalculates spreadsheets immediately. Potential usages are getting cost-, energy-, calculations immediately while modeling or generating models from data.
Last month I worked on:
Communication between „interactions“ (a state machine) and the different UI elements
Implementing first CAD primitives
All is done in C with OpenGL and a few header-only libraries.
my language ai is a simple language with primitive support for object orientation, with primary focus on simplicity, communication with C libraries and adding few syntax sugars over C. If ever get to creating an operating system I will use ai in the project :D
The language is effectively a statically-typed scripting language, since it doesn't require the code to be contained within procedures.
A weird mix of C, Pyhon and Go heh.. :D
As of now, I'm working on writing a robust parser. The langauge is just starting, and there isn't much to show. However I'm planning writing a custom backend with an optimizer
The game is a 2d/3d rpg set in the fantasy world of Illoway. As the heir to the throne you must collect the 7 dragon heart stones to bring peace back to the realm.
It will have a mixture of puzzles, quests, dungons, and conversations that will hopefully be fun and unique.
It's written in C using SDL and OpenGL. I want to experiment with 3d graphics techniques in the 2.5d world. Things like shadow maps, bloom and lighting.