I recalled what it was about before even clicking the link, and I've only seen it once. You are really good at making people remember your products. The first time, I thought it was a hoax, or a FNAF variant because of the design of the robot and the tone of the website, but if it happens to become a real product, congrats, I hope you'll find success with it.
I've always had a sweet spot for using C for pet projects. For some reason, I find it soothing to work with the language. I think there is still room for this language to be taught to beginners.
That seems like a fun idea, but are you going to vibe code this indefinitely? What if Claude fails because of to the increasing complexity of the code, are you gonna abandon the project?
It’s a good question. To be honest, I don’t know yet. In the past couple of days it felt like I might have hit a wall but it turned out a lot of cruft and cargo curled ideas had ended up in Claude.md…
At the moment I’m having more fun adding features than playing it.
A C++ lib to write SIMD code like you would write GLSL: CPPShader https://github.com/gitdepierre/cppshader. I need to clean up the code a bit right now, and I'll add SSE2 support for older CPUs (currently requiring SSE4, but I want to see it working on C2D and Atom. I just need to replace the blendv functions with something compatible with SSE2). Then I'll focus on adding NEON support.
I had the same thoughts about SIMD code being too verbose when I wrote some, so a few months ago I tried writing a library that lets you write quasi-GLSL code in C++, so much more compact, with the ability to switch between SIMD width without having to rewrite anything at all:
Is GLSL more "approachable" than SIMD? For me personally (who doesn't have any graphics programming experience), GLSL feels way scarier than SIMD, especially when you look at the black magic that happens on shadertoys. Not saying GLSL is actually hard, but for a programmer like me SIMD might actually be more approachable
You're right, GLSL can be a bit confusing at first, especially swizzling, and the idea of writing your kernel only once then relying on the input data to drive your logic. But once you get used to it, it's very practical for writing complex stuff in just a few lines of code, it's really fun, and that's what you see a lot in Shadertoy.
I got the idea to write the library when I wanted a simplex noise function in C++, implemented with AVX2 for performance reasons (because why not). There were a lot of public HLSL/GLSL implementations that were concise and fast on GPU, some of which I had used for years for my own needs, but rewriting the whole code in plain C++ would have been a hassle, and i would have to do the same for every GPU code i came accross in the future, so building a wrapper seemed like the most efficient approach.
So in the end, the library is mostly aimed at people coming from the GPU world who want to keep most of their habits. But yeah, there is probably very few use cases for it.
