Speaking of Dear ImGui, I recently wrote a super minimal Profiler/Flamegraph for it. The model and profiling logic is ~60 LOC with the UI adding another ~50 LOC. It's written in Odin but is so simple, it should be trivial to port to other languages and UI systems.
https://alek-tron.com/FlameGraph/flamegraph.html

Nothing big but I wrote a custom Windows/DirectX backend for Dear ImGui.
On one hand to just have a native Odin backend. But also to serve as an easy introduction to others who would like to integrate imgui into their own renderers/OS layers, like I used to do. It doesn't cover all edge cases and features like the official backends, but that let me keep things simple.
https://github.com/alektron/imgui-odin-backends

An article I wrote a while ago about the confusion of texture coordinate systems and how they do (or don't) differ between OpenGL and DirectX. And why you don't need to flip your textures for OpenGL:

https://alek-tron.com/TextureOrigins/TextureOrigins.html

Picked up my old space sim project again and made the flight trajectory planner multithreaded. Each color is a separate thread.
The thing is, the calculation of an object's motion in an N-Body system is strictly serially dependent so "actual" multithreading is not possible.
What I am doing here is letting each thread calculate with a bigger timestep than the previous and then stitch the results together.
So I at least get a lower precision result sooner, until the next thread catches up.
Might look a bit unimpressive but in total the highest precision thread is calculating 21 Million values so speed is quite of the essence.

I just published my little game "Chunk Miner" on GitHub (https://github.com/alektron/ChunkMinerGame) and itch.io (https://alektron.itch.io/chunk-miner).
It is written almost entirely from scratch in just ~3200 LOC in Odin with the only major dependencies being stb_image and miniaudio (no SDL or raylib).

It has everything a game needs including, among other things, a D3D11 renderer, immediate mode UI, Saving/Loading, particle systems, minimal platform abstraction layer, OBJ parser etc. (more exhaustive list can be found on GitHub).

A lot of effort was put into the code structuring. I wanted it to be easy to understand, extensively documented, no cruft, so that it can be used as a codebase to learn from. Developing games without a third party game engine seems daunting, but it does not have to be. A lot can be achieved with little and this project is meant to show that.

I've been working on a spaceflight sim a while ago and of course could not resist doing The Interstellar Scene™

My little VR game I released last year
https://alektron.itch.io/fear-of-falling

It's written in C++ with OpenGL, ImGui, PhysX and OpenVR.
The physics based movement was a real challenge to get right. I wanted the controls to feel very tight. No jank or spring-like behavior of the climbing hooks that are used as an extension of your arm. This rquired its own little physics system on top of PhysX. Eventually I heavily cut down on content or I wouldn't have finished the project, so the areas where this precise control would have really become necessary, didn't make it into the game. Nonetheless I believe the movement system is something rather unique.

The screenshots show the editor with built-in lightmap packing and baking, among other things.
For lightmaps baking I use https://github.com/ands/lightmapper, a system inspired by the lightmapping of The Witness.
Especially considering its simplicity the result are pretty good. Even if baking times were quite slow.

DXF Explorer is a tool I made to help analyse the .dxf file format.
It's a format very widely used in CAD software, the documentation however is of course terrible.
While human readable, it's also incredibly cumbersome to navigate in a text editor.
The tool parses DXF files on a relatively high level and presents it in a way that is much better to work with.
It is mainly intended for devs that have to write code that is reading/writing DXF.

I wrote it as an ImGui app compiled to WebAssembly. Data gets processed 100% client side.

https://alek-tron.com/DxfExplorer/

As promised in my last post, here is a little demonstration of my memory viewer/editor.
In the first video you can see a classic recursive fibonacci sequence being executed. Since the stack is also just a structure in memory, the memory viewer can show the stack as well as other allocated memory, like the array for the fibonacci results.
Pointers get red lines drawn to the destination they point to.

The second video shows what the memory for a bitmap looks like, that is being written to in realtime.
At any time, even while instructions are executing, I can edit the pixels (or any other data) by hand.

My compiler/runtime/debugger/(memory visualizer/memory editor, not included in this video)

Quick explanation of what you can see here.
On the right is the code that got compiled (with an AST visualizer below).
On the left is a UI for all the types and functions that got generated.
Next to it are the generated instruction with an indicator for the current instruction pointer and a "speed" slider on top to run the instructions.
Next to that is just a print output and next to that is a visualization of the call stack.

When the code is run you can watch the instructions execute, the call stack grow and shrink, frame variables getting initialized and edited.
The "types" UI on the left also includes "Stack frame" types. You can imagine them as structs that describe the stack frames. When hovering over such "struct" members, they get highlighted in the stack frame visualization.

I will show the memory visualizer/editor another time. It's an interesting experiment as well.