Compute shader graph.
C++, Dear Imgui, SDL3-GPU

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.

Very very basic beginnings of the beginning of RAW image processing.
Basically just a simple GL app that uses libraw to read a Nikon .nef and demosaic it. (plus some largely incorrect adjustments)

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)

Payoff from implementing custom rendering in UE5.
Once you get it all set up, everything past that is just HLSL.
The water "particles" are currently simulated on the CPU and uploaded into a buffer for drawing into an intermediate texture.
Eventually the sim will be done in a compute shader -> indirect rendering.
Still lots of things left to add.

Not exactly a project, but I made a simple barebones Blender mesh exporter script. It outputs vertex and index buffers ready to be sent to the GPU.

(Should this be in library? Even though I wrote it myself?)

https://gist.github.com/kanzwataru/a703e07e33b1d64df6c0ea07157590b3

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.

Not exactly a project, just decided to hello-world a PSP. This is actually a no-abstraction GPU-rendered version of the initial SDL2 version I made to get the ball running. Needless to say it's a lot faster (doesn't lag at all). The PSP is quite interesting, it's surprisingly powerful for a 2002 handheld. The GPU API is similar to OpenGL 1.x but without the glBegin nonsense (goes straight to vertex/index buffers). I was somewhat skeptical of the (unofficial) pspsdk, but it's actually very Handmade in the sense that all the sce* functions actually are either just jumps into the kernel, or just raw assembly to send out commands to the GPU.