For whatever reason I decided to switch to Arch Linux on my primary laptop. I had been using Manjaro somewhat happily for a while, and figured I could use a change. Also, there was a weird week or two where my audio controls just randomly went haywire. I’m not sure it had anything to do with Manjaro, but the maybe was enough to get me to start thinking about other distributions. Some similar impulse was how I ended up on Manjaro in the first place (previously Debian).

I had bailed on an Arch installation before, but I figured, if I wiped my main laptop and went for it, I’d have no choice but to go all the way. I figured, as long as I got into a GUI and a web browser, I could handle the rest as I realized I needed it. What I didn’t realize was that it would be another 3 hours of typing at the CLI before I finally figured everything out.

It has you start from formatting your own boot partition. Having spent some time repeatedly formatting and partitioning SD cards for my Rasperry Pi stack, I wasn’t super worried about this.

Things got annoying when I realized the network doesn’t come set up out of the box, which is a problem because you need that to install stuff on an OS that comes with nothing installed. So that’s when I learned me some iwctl. It’s actually a pretty handy tool and I’m probably actually going to come back to it some day for a real-world scenario, but also takes an extra step to get it to handle DHCP. Even now I don’t fully understand Linux networking. Every little function and layer is split up across config files and daemons all over the place.

And then it came time to get the GUI going. I think what I have here is the Plasma desktop environment, on top of an Xorg display server, using the SDDM display manager. Something went wrong along the way and I found myself looking at the X windows without the Plasma layer on top, and wow that was pretty horrific.

Anyway, I think I’m out the other side, almost to the point where I was in Manjaro. Maybe need to tweak some themes a bit. Jury’s still out on this Gruvbox console theme.

So I just went through another round of rewriting to make things work, which paved the way for some more aesthetic features.

One was my “RaceText” class, which for now is just used to notify that a car is coming in. At first I just had the text pop up on the screen, which was boring, and then I had it come in on an easing function, which was fine but I figured I might as well make things more annoying for myself.

The RaceText class takes any string in its constructor, and assigns an animator to each character and has them come in one by one. It’s fun but the kerning is completely wack because I’m not using a monospace font. One of these days maybe I’ll just make my own.

class("Asphalt").extends(gfx.sprite)
function Asphalt:init()
  local asphalt_img = gfx.image.new(600,160)

  gfx.pushContext(asphalt_img)
    gfx.fillRect(0, 80, 600, 160)
  gfx.popContext()

  local asphalt_blurred = asphalt_img:blurredImage(20, 8, gfx.image.kDitherTypeBayer8x8)

  Asphalt.super.init(self)
  self:add()
  self:setZIndex(-100)
  self:setCenter(0,0)
  self:moveTo(-100,100)
  self:setImage(asphalt_blurred)
end

The other fun thing was the ground graphic, which I decided I’d make programmatically rather than just sticking in a static image. I’m not so sure the image would have been any easier since I’d have had to get into Gimp, make the thing, add to project, compile, play, hate it, delete it, repeat. Doing it in code gives me a lot more control over the variables until I decide it looks right.

I don’t know of a more direct way of accessing the dithering functions in the SDK, so I just resorted to drawing a big black rectangle and then running it through the blur function, which allows you to specify which dither function you want to use. Since all the graphic work is done once, right on initialization, so I don’t need to worry about any performance hits.

I decided today that I didn’t really like the filenames on these markdown files for the blog. They look like this:

2022-11-22-hello.markdown
2022-11-25-pardon.markdown
2023-05-16-inspiration.markdown
2023-07-09-Devlog.markdown
2023-07-10-Devlog.markdown
2023-07-13-Devlog.markdown
2023-07-14-Devlog.markdown
2023-07-16-Devlog.markdown
2023-07-20-devlog.markdown
2023-07-21-devlog.markdown
2023-07-24-devlog.markdown
2023-08-08-eink.markdown

I wanted it to look like this:

000_22-11-22-hello.markdown
001_22-11-25-pardon.markdown
002_23-05-16-inspiration.markdown
003_23-07-09-Devlog.markdown
004_23-07-10-Devlog.markdown
005_23-07-13-Devlog.markdown
006_23-07-14-Devlog.markdown
007_23-07-16-Devlog.markdown
008_23-07-20-devlog.markdown
009_23-07-21-devlog.markdown
010_23-07-24-devlog.markdown
011_23-08-08-eink.markdown

I’m not sure if padding to 3 digit index numbers was being a bit ambitious for this blog, but I just wanted something to make the tab-completion a little easier when working with these files.

So I wrote this little thing:

i=0
for filename in $(ls *-*-*-*.markdown | sort -n); do
	newfile="$(printf "%03d" $i)_${filename:2}"
	echo $newfile
	mv $filename $newfile
	
	((i++))
done

And it did just that! Except afterwards I realized Jekyll only likes it when you format your files with the date first.

So, that script will just have to live on this little branch forever unused.

My Boox Tab Ultra C just arrived and I’m having a pretty good time with it already.

I took advantage of the “back to school” deal that included the keyboard cover.

Why not just use a laptop, you ask? Now I can sit in the backyard in direct sunlight and the e-ink display only makes the text more visible.

It took some messing around to get set up the keyboard with a grave escape, but now that that’s done I pretty much have my beloved 60% layout. I’m using Termux to get me a *nix command line and from here I can SSH out to my stuff.

Obviously the Playdate dev work won’t be happening on this but so far writing this blog post in the backyard sun has been delightful and I am getting tons of sunlight.

So I’ve finally gotten around to implementing a timer, which is sort of the point of this whole thing as the primary metric for scorekeeping. I’d been holding off on doing it because so till now I hadn’t had to do anything with dynamic text on the Playdate.

You get playdate.graphics.drawText() and not a whole lot else. If you just call that, you get this:

This happens because it’s just spitting the pixels out on the screen. What you need to do is clear them out for every frame and redraw it. There’s playdate.graphics.clear() but that clears the whole screen, which may include a good deal of pixels you don’t want to have to redraw.

This is the power of graphics.pushContext(). It’s weird how push and context together made no sense to me at first, but what is happening is that you’re switching the context of every graphics command to, for example, your sprite (by default, it’s the screen buffer itself). All of the x’s and y’s become relative to the origin of the sprite, and also, importantly, graphics.clear(). Now it only clears the bounding rectangle for the sprite you’re working on. When you’re done working in this context, you call popContext() and carry on.