As people asked for better decompression speed in my bc_crunch lib, I started experimenting with Huffman coding. First results look promising: compression ratio is still better than zlib (~1.52:1) and decompression reaches ~144 MB/s.
github.com/Geolm/bc_cru...
(BC1 only for now)
nope, as you said it's complicated to get it done properly, I don't have the need ATM (not fan of the property grid everything) and it would add a lot of LOC to me lean lib.
I didn't had the luxury to work on my personal projects during the holidays season but here's a video of my attempt to animate my creature using position based dynamics (distance/angle/elbow constraint + ik).
also with multiple quads and alpha blending you have more overdraw and r/w access to the framebuffer compared to tile rendering. Another point is primitive smoothin and boolean operation that are only possible with tile
got a 404 error when trying to access the pdf...
People kept asking me to compare bc_crunch with zlib, so I finally ran the tests. Overall, bc_crunch comes out ahead. More details are available on the GitHub page.
bc_crunch BC1: 1.580368 vs zlib: 1.436144
bc_crunch BC4: 1.327702 vs zlib: 1.104125
I used miniz with the highest compression setting
another note : BC5 ratio is pretty bad at the moment because it treats the image as two independent channels. One solution would be to create a new function only for normalmaps that exploit inter-channel prediction (not planned for now).
btw I also found some small improvements for BC4, ratio went from 1.23 to 1.29
I understand, I might need that at some point too, if so I'll update the lib.
I don't know, I did not try nanovg. Onedraw supports less features for sure. I wrote this lib for my own needs and to try some ideas I had in mind, not to compete with others libs.
Hey, I thought I was done with bc_crunch, but I tried one last idea: Inter-channel differential coding.
It works pretty well. The average compression ratio for BC1 went from 1.494:1 to 1.580:1, finally breaking the 1.5× barrier.
It's already available here: github.com/Geolm/bc_cru...
Do you mean using a texture map as a probability field for spawning? I'm curious, what would be the use case?
Haven't done a camera analysis in a while!
Here's a quick look at the camera for Metroid Dread 🎥
Experimenting with a new control: a knob :) It should land in the public leanUI library soon. And yes, I’m working on a synth… stay tuned (pun intended).
As a Canadian, I can tell you the shovel sound is a bit off. You only get that bright metal-on-concrete noise when the ground is bare. Most of the time there’s a layer of packed snow or ice stuck to the concrete, which makes the shovel sound more muted and less metallic.
no the post can't be that long !! ;)
Needed a simple way to spawn 2D objects (grass blades, stones, etc.) in composite shapes or along splines, so I wrote this: github.com/Geolm/spawn2d. It’s minimal, single-file, and easy to drop into any project.
Uniform Catmull–Rom spline sampling with disc collision and exclusion zones. Poisson-like, but curve-specific.
Working on a uniform sampler with dynamic exclusion zones for procedural gen. Solid results so far, code release is possible once it’s cleaner.
currently no, TBH it's not planned since my goal was to have a quick way to export video from my games/renderer. Feel free to fork the repo and add the features you need.
Just released a single-file C99 library to create MJPEG AVI videos from an RGBA framebuffer.
github.com/Geolm/mjpegw
Like jo_mpeg, but MJPEG gives higher quality (larger files).
• 3-function API
• No dependencies
• No audio
• Plays in ffmpeg & VLC
Huge thanks to Tiny-JPEG for the JPEG part.
Also, there’s a benchmark in the repo at /test/benchmark.c that profiles BC1 crunch/decrunch—make sure to compile with optimization flags.
Some optimizations news: NEON + decoder table in bc_crunch → decrunch ~1.5× faster, crunch ~1.3× faster. No plans for more performance tweaks right now, but I left some ideas in the README. Ping me if you want to chat about them!
Hi everyone! Thanks for the interest in my library bc_crunch. Quick update: I’m currently working on optimizations. Two major bottlenecks have been identified, and fixes are on the way. I’ll share some performance numbers soon and add a profiling test to the repo.
I’ve updated the BC4 algorithm and I’m curious whether it improves the compression ratio on your textures as well. For reference, my AO/displacement map went from 1.051032 to 1.211644 (a 15.3% gain). I have still some ideas left, I will try to continue to improve more.
Update, I changed the heuristic for BC4 streams, went from an average ratio of 1.051032 to 1.211644. Tested on AO, displacement map (check textures/bc4 folder)
Thanks! I haven't had time to profile decompression yet, so that measurement is really helpful. Would you mind if I add that number to the project page?
Thanks for the feedback! I agree on BC4/5 — right now it’s a bit hit-or-miss and too dependent on input noise. The algorithm still needs improvement there. I’m currently building a BC5 test texture set, which should help compare different approaches more reliably.
Don't hesitate to message me if you find a bug or if you have a question or feedback. I will update the readme with the BC4 benchmark soon.
Just released bc_crunch: a tiny (~700 LOC), C99 library for lossless BC1/BC4/BC3/BC5 compression.
One .c/.h pair, no deps, no malloc
GPU-ready output
Zigzag + delta + popcount/dictionary tricks
Tested
Perfect for games, procedural assets, streaming textures.
github.com/Geolm/bc_cru...
