I just released a cross platform C

A little more work on the (still-early) RAW editor, there is now a gamut plot in OKLCH colour space.
Cranking up the chroma shows the colours falling out of sRGB gamut.

Next step is gamut compression/gamut mapping!

Playing around with Raylib, got a basic node editor in <250LOC.

Added histogram and tonemap visualizer to my camera RAW editor &filmraw. (Odin/OpenGL/Dear-Imgui)

Visualizing the data makes manipulating it a lot easier, so I will add more of these before implementing any more colour editing features.

https://github.com/kanzwataru/MinimalGraphicsExamples/blob/master/minimal_gpu_skinning/minimal_gpu_skinning.c
Jumping on the minimal graphics example trend,
I made a small 250-ish line long mesh skinning example.
The mesh is defined inside the code, and normals are left out, but it should be good enough to get the gist for anyone trying to implement skinning.

(disclaimer: unlike :d7dealwithit: or :martins: , I do not have experience measured in decades)

Submitted an entry to gbcompo21! First time writing something substantial in assembly. A lot of the low-level basics learned from HMH helped a lot, making me more able to make more use of the hardware. Everything is 100% from scratch, no libraries of any kind either in the game or the build/converter tools. Wrote exporters for Aseprite and Tiled, and the code for processing the assets and putting it all together was all just plain old C, nice and easy. A lot of the day-to-day stuff at work (gamedev) applies to this surprisingly directly.

Also due to this I missed out on the Wheel Reinvention Jam! Drats!

Working on the "engine" side of a game for GBCompo21.
The standard way of doing music for GB seems to use a tracker that produces data for a "driver" that runs on the GameBoy and interprets it and writes to the sound registers. But a lot of these drivers are huge balls of code and I didn't want to use any libraries on the GB side so I considered whether I can do what Id Tech MS-DOS games do and simply take a big ol' dump of per-frame sound register values and compress it. This is vastly simpler than the driver approach and the code is very small and fast. The compressed data size is comparable to the data for the driver approach, only slightly larger (depending on the ring buffer size).

The way it works is I have a rudimentary LZ compressor that is aware of the decompressor implementation on the GB side. The GB decompresses a frame's worth of register values each frame into a 2KB ring buffer. The buffer is used for the LZ decompression's back references. Since it only decompresses at max 40 or so bytes per frame it takes very little CPU time. A complicated example song exported from Deflemask tracker weighs in at around 62.7KB and is compressed down to 14KB. My compressor is very quick'n'dirty so it's also likely possible to compress it further.

The video is of the BGB debugger showing the ring buffer in memory.