Finishing up the wgpu book
After I noticed that some kind of prograstination started to creep in on the broader task of finishing the wgpu book, I knew I had to do something against it. (I guess sometimes I'm just bad at doing the last 5 percent needed to finish up things in general). There was only one chapter left in the book I was reading and it was about drawing complex functions, e.g. stuff that's related to the mandelbrot set visualizations you are probably aware of. At first glanceit was kind of obvious that there was not much left to learn in this chapter which made it even harder to complete, but I sat down and did it anyways.
It was necessary to implement some small utility functions for working with complex functions for this chapter. After doing that the only real interesting part of the chapter came up in my mind: How do I actually include the utility functions in math.wgsl in my main shaders main.wgsl? Knowing the codebase of bevy a bit, I naively tried the same stuff they did there to import the math utilities:
#import wgpu_book::math
// rest of the code ...
But to my surprise this didn't really work out. Taking a look at the wgsl specs revealed that this isn't really a feature in the vanilla feature set of wgsl (yet). The people at bevy are probably running some kind of preprocessing step to resolve these import statements. In the end I followed the steps that were taken in the book which are basically happening on the rust side of things:
let shader_math = include_str!("math.wgsl");
let shader_main = include_str!("main.wgsl");
let shader = [shader_math, shader_main].join("\n");
This was as lame as it could get but at least I know a way of getting this to work now.
The visualizations were pretty cool in the end, but there was not much to learn as already mentioned. The author of the book mainly copied the shader code from the shadertoy website and other github repos aswell so, .... yeah. At least I'm done with the book now and can place a big, fat checkmark on the task.
Maintaining codeberg-cli further
One user opened an issue on the codeberg-cli project where they mentioned that the fancy output of the program should've been an opt-in feature and that simpler output would also make it much more easier to parse it. I agreed and dedicated two evenings to improving on the situation. I went for what was suggested, restructuring a lot of the "rendering" code in the crate. The simpler output was still in a table format which was space separated. This seems to be the right choice until you notice that some of the table cells could contain text (sentences) which naturally contain spaces. To solve this I just did a hack and surrounded all text cells with " characters.
After letting this first draft sit for a while, I noticed that this was probably flawed for some cases aswell. The realization kicked in that it was probably a bad idea to create another hacked-together output format for an CLI app and so the next design was drafted: The fancy output will remain the standard output and we will add an opt-in --json flag which returns the data in JSON format. This should not only solve the issue of creating a format that is easy to parse and valid for a lot of output possibilities. As JSON is an iNdUsTrY sTaNdArD, it should be easy to parse in general and there probably already exists some tooling that will help you with that.
I'm still waiting on some feedback of the user that requested the feature but I think I'm going to implement it like this the coming week.
Visiting C3D2
In the past week I finally found the courage to go to the C3D2 hackspace in my hometown again. It was a cool space and the people there were very friendly to me. In the future I want to work on a special project when I go there:
The first time I went to C3D2, someone was mentioning that they might want to do something with an E-Ink display. Since I wanted to do some simple programming on my reMarkable anyways, I thought that was a good fit for me. And so began the story of me trying to figure out how all of this stuff works. I looked up some rust crate that was meant to be for working with the reMarkable on a low level. It's called libremarkable and seems promising. Once I get my old reMarkable 1 back I will definetly test it out!
When doing a bit of reasearch, I also stumbled upon someone playing a video on the reMarkable which made me extra curious. I think it ran at about 15 fps which was already kind of impressive. After continuing the research I eventually found someone who created their own E-ink display which was made for running videos. They played the same music video at around 60 fps which amazed me completely. They even open-sourced the whole project here. I'm not at all familiar with hardware schematics but I took a look at the mainboard plans anyways with kicad. It was pretty impressive but I'm not really sure if I want to start learning how to read/write these board layout plans. I eventually found a company that can just produce the boards for you if you send them the plans, but even then I would still be completely lost and wouldn't know how to continue. Let's see, maybe I'll figure out a way how to use that stuff eventually.