Jach's personal blog

(Largely containing a mind-dump to myselves: past, present, and future)
Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

Hello World to get with the times using SDL2 and Common Lisp

Long ago I learned how to program simple 2D games using PyGame. PyGame was built around a C library, SDL 1.2, and both presented a very attractive model for programming 2D games that followed from some old-school techniques. Specifically, the structure of your game was built on the assumption of a single CPU talking to a video memory buffer used by the display to show pixels. If you wanted to make a 3D game, you could do it classically with a pure software renderer, controlling every pixel. Of course to be more useful SDL allowed you to setup an OpenGL context, so you could make a 3D game taking advantage of graphics cards, but you'd do it with OpenGL; SDL wouldn't help you with the actual video part of that, though it remained very useful for input polling, sound, and other game programming aspects.

Times have changed, and almost everyone has some sort of 3D acceleration hardware even if it's bundled with their CPU. CPUs have more cores. Resolutions are higher. More people have multiple monitors. The optimal graphics pipeline is very different than it once was. CPUs are also faster, so it's not like you can't do software rendering, but you're leaving a lot of performance on the table that could be used to do more stuff per frame in your game. So SDL2 was made to address modern realities while keeping a nice high level API to create 2D games. Things aren't that different, but now you can get a huge performance boost, because SDL2 will do hardware stuff behind the scenes on your behalf.

I've played with SDL2 a few times since it's been out, and each time left not too satisfied. For some reason I never bothered to read the Migration Guide. Reading it this time I've convinced myself SDL2 is the right approach and worth relearning a few things and changing approaches to take advantage of it. In other words it's time to get with the times. The guide also explains the main approaches people have used to make 2D games and how each approach can be, with few drastic changes, done just fine with SDL2, but now can be much faster.

See Full Post and Comments

Draft - vim Introduction and My Setup

Note: This blog entry is in a draft state and given my laziness likely to stay that way indefinitely.. In particular the "trying to program" bits at the end are just notes of how I want to flesh them out. Maybe I'll write them up at some point -- if I do they'll probably be separate posts and I'll edit this one to link to them.

It seems everyone who uses vim eventually winds up writing something like this... Out of the box, vim (and its long-ago predecessor vi) are very capable for their primary purpose: editing text. But vim has a powerful extension system, making it capable of so much more. In addition, the out of the box stuff is very configurable, so even if you install no new plugins, you can spend a lot of time tweaking the settings to get what you like. As such, this is my vim setup. Your preferences may very well be, and may very well should be, different.

See Full Post and Comments

Some thoughts on test automation

I found an old piece of paper from ~2014 that had some bullet points on testing philosophy I had back then, mostly to help myself articulate things in interviews. Reading through the list I still believe a lot of them, but others not so much or I have more qualifications. Let's look at them, elaborate, and add some thoughts not present then.

* Code should be designed for testing -- create hooks/test points (if hardware) if necessary. Want to facilitate "white-box" testing.

Mostly makes sense to me. This has larger implications though depending on language and test type and how exactly you're designing for tests. The very worst design idea is to have code like "isRunningTests()", and to make worst worse have code inside such blocks doing things like "getTestContext().getProperty("blah")" to use for the code instead of whatever the real thing was.

See Full Post and Comments

IT'S OVER 9000!!!!!

What?! 9000?!

(I only get to do this once.)

(Vanity update 10/31/22: I don't think I've tried very hard over the past 2-and-something years for karma but here we are.)

See Full Post and Comments

Blog rewrite notes - postponement?

As mentioned in the first post, this blog was running on some pretty ancient infrastructure... well over the past couple of nights I finally decided to do something about it.

The first thing to go was the old Ubuntu 14. Instead of creating a new image on say Ubuntu 20, though, I went with my favorite OS (and the one I use for my PC): Gentoo. Some time ago I remember trying to build my own Gentoo on EC2 with some tooling, but it didn't work. In the end this time I went with an unofficial image.

As usual be careful of your trust tolerances -- I don't know anything about this group other than they've been around offering this thing for years. I spun up a new instance and poked around, it really is quite minimal (excellent!) and nothing crazy jumped out.

See Full Post and Comments

Blog rewrite notes - serving the front-end

Last time I wrapped up the actions that the server needs to support. This time I want to write a bit about how I ultimately want to render the front-end...

Starting with how it currently renders, it's done in a rather classic server-side rendering way. I have several "template" files that organize the site content, and each request is handled by applying some template to the dynamic content and sending down the HTML with no further interactions needed.

I'd like to keep everything as noscript friendly as it is. I really dislike the direction modern sites have gone of needing JS for everything, even if there are advantages depending on the tradeoffs you want to make. (Headless CMS is increasingly popular for instance.)

See Full Post and Comments

Signs of Fear Driven Development

Note this is sort of a draft/WIP post... I intend to update this sporadically as I notice or re-notice new signs and perhaps rewrite in a more organized manner one day. If you're skimming, the signs are in bold text.

I've written a bit about FDD before but it's probably worth calling out separately and compiling a list of signs you, your team, or your company may be suffering from it. And possibly some suggestions for ways out.

Today's trigger for the post was actually another software evolutionary branch that got cut off with the demise of the Lisp machines. Take a look at this tweet and its replies:

See Full Post and Comments