2021-08-30 Nvidia decided to deprecate the drivers used by my graphics card and when Ubuntu rolled over to the 5.8 kernel something broke and X server wouldn't start. The open source nouveau drivers didn't want to play nice with the monitor which refused to display any resolution other than native despite them being supported. It might have had something to do with refresh rates somehow but I never figured it out. Finally I took it as an excuse to switch to Windows which had been on my mind for a while anyway because of other stuff like sleep mode not working properly.

Windows 10 turned out to be not all that awful and the hardware support was undeniably better. It's nice to have things like switching between monitors finally work.
I missed i3 though even if Windows now has multiple desktops and some primitive tiling ability the keybindings never felt right.
If you want to do C development you had to download something like 25Gb of Visual Studio libraries which was offensively excessive so I stuck with cygwin which worked alright but eventually I got tired and switch back to Ubuntu where now the nouveau driver worked with different resolutions for some reason. Maybe they fixed it in the interim months or I had borked something before.

I've been considering upgrading the computer since it's pretty slow anyways, though I'll wait till the chipocalypse is over and see if prices go down. Windows 11 also appears set to deprecate a lot of perfectly fine computers that don't have a TPM 2.0 module so hopefully those will start flooding the market at the end of the year.

There's been one small update to --C to only allow constant pointers to be returned from functions in order to make sure globals are not manipulated outside setters. Otherwise I've gotten bored with that project for the moment.
Also I was briefly experimenting with custom Vim key bindings. Vim always felt a bit unnatural and I've never managed to become great at it since I can't remember all the commands and different key-combos. Some keys are positional like hjkl and some are literal like w and b and others feel like they've just been crammed in wherever there was room. It also isn't entirely modal as there are plenty of quasimodal commands like C-d and C-u which is unpleasant.
So I placed the most common movement keys on the middle keyboard row and above the left fingers with the middle and ring finger doing small movements and the index and little finger doing larger movements. It kind of worked but I ran out of keys for all the stuff I wanted to use which is likely the same thing that happened to Vim itself so I gave up on that project. Getting used to some custom key bindings didn't seem like a good idea either. I fell into a similar trap years back when I decided to change the keyboard layout to Dvorak. It took a while to get used to and it never improved my typing speed but it made using other peoples computers a real pain as I found I had forgotten qwerty and had to go back to hunt and peck. From that I learned that it's better to stick to the lingua franca like qwerty or regular vim bindings for reason of mobility.
The only thing I've retained from the experiment is to have line movement take into account screen wrapping which is really helpful when working on prose documents were you have longer paragraphs that can line wrap multiple times. For those interested the .vimrc remappings are:

"Line up.
noremap k gk
"Line down.
noremap j gj
"Beginning of line. Starts with 'b' so it will automatically jump to the previous line if you press it twice.
noremap 0 bg0
"End of line. Starts with 'w' for the same reason as above.
noremap $ wg$

Other than that I've been puttering away at Orbz3D again and have plans for another AI tutorial but it'll take a while before any of those reach fruition.

2021-05-09 Did a review of the book The Sacred Mushroom and the Cross and had some thoughts about switch statements.

2021-04-11 So I've found another little side project that's turned into a bit of a rabbit hole. This one involves parsing a C source file which turned out to be a none trivial undertaking but I think I've got it worked out and hope I can publish something about it soon.
Other than that I've written a short review about a recent keyboard purchase.

2021-03-09 Wrote a page for rendering floors and ceilings in the raycaster engine and some musings on control schemes. Also had to do a slight update to the raycaster tutorial because irritatingly enough I was off by one when calculating "yScreenBottom".
Moved all the blog posts from 2020 to their own page.

2021-02-20 Finally got done with the raycaster tutorial. Mostly anyways, floors and ceilings are implemented but not explained yet. It's been sitting half finished for some time so I somewhat rushed it just to get it out of the way but hopefully it's still comprehensible. I'll add floors and ceilings later or as a separate page.
One problem that cropped up was compiling the example code for WASM. Because the code leans heavily on recursion it becomes a necessity to have tail call elimination but this just recently got added as a proposed feature for WASM. Chrome has an experimental implementation of it though and the only way of seeing the little game at the top of the page is with Chrome at the moment.
WASM has probably inherited this lack of proper tail calls from java script where it's a feature in the language that no one but Safari implements. It was surprising to see that this wasn't in JS considering all the other features it got. The most popular programming language with millions of users and no one uses recursion enough to need it? It certainly throws some doubt on the story that JS is inspired by Scheme...
After rereading Moses and Monotheism recently I wrote a short summary.
Also I found a broken laptop with a stick of 4GB PC3 memory in the trash! Found another 4GB stick a year ago so now I'm up from 4 to 8GB in the laptop which is nice.

2021-01-03 A new year. But will I piddle it away like all the others? Most likely. I added something about the origin of the name of the Demiurge in Gnosticism, Ialdabaoth.
When writing Orbz 3D I got stuck on how to rotate objects in 3D. At first I was going to use an algebraic solution. Stated simply the problem was finding three variables, the x, y and z coordinates for the new 3D position after doing the rotation. As we know from basic algebra three unknowns requires us to have three equations in which the variables are used in order to find what their values are. The three things known about the rotated position was the dot product, cross product and the equation for the 2D plane in which it had to exist. Cross product being a vector and not a scalar value you also had to use it with a second vector to get another dot product.
Solving something like this is not terribly complicated. You can break it down into a couple of steps when doing it on paper. When doing it in a program however those steps had to be compressed into a single one and I thought it looked kind of ugly and it wasn't easy to explain what was happening. Instead I found a way to do it using geometry that was a lot more intuitive. I tend to favor geometrical solutions since when you have something visual it is much easier to reason about the solution and therefor remember how it works. It's one of the best areas of mathematics.

Other than that I've been implementing some more small changes to how I program. I found myself often using negative numbers to signal the absence of something. For example each orb in the program can have a parent associated with it, which is another orb who's actions like movement and rotation it can be made to mimic. A parent is then defined as just an integer that represents an array index at which that parent is located. So e.g. the orb at array index 5 might have a parent of 7. So these parent values for all orbs where stored in an int array and since they represented array indices they were only supposed to be positive - negative array indices are of course valid in C as an array is just a pointer but I've never seen this used and can't imagine it to be a good idea ever - so then the array can be of type unsigned int. However some orbs might not have a parent and what I usually do in these cases is use -1 to signal none. If the parent array then had -1 in one place you knew that that orb didn't have a parent.
This though if you think about it is a bit wasteful. You're giving up half the possible values that the array can hold. If an unsigned int can be between 0 and 65,535 then a signed int can only contain the numbers -32,767 and 32,767, and on the negative side you'll only ever use -1, all the others go unused. This might not matter in practice since the program won't ever approach 32 thousand orbs let alone 65 thousand but it still irked me that the parent[] array was now being used for two different purposes: Indicating whether an orb had a parent or not and also storing the value for that parent if it had one.
To make things more explicit and to me clearer I made a bool array called hasParent that is for indicating if an orb has a parent in the first place. The parent[] array can then be made of type unsigned int and each array now only does a single job.
Similarly there was also a function called find_orb() that took an "orb id" and returned an index to an array where that orb could be found. If it didn't find any orb with that id it returned -1. Again I thought this caused confusion since the return value of the function now essentially was variable. The nature of the return value is either a bool representing false if no orb is found and it returns -1 or if one is found it will return a positive integer representing both true and therefor being a bool while simultaneously also being an integer representing an array index. Sure, you can use a define or constant to label the value -1 to something like NONE but I felt this did not get rid of the inherent ugliness in having one number represent multiple things. Modifying the function to only return a bool to indicate found/not found and having it place the array index in a passed in pointer I thought was a neater solution.