After a long period of not posting, I present my latest doodle, just in time to see off 2020.
You can try it out on kubernetes:
kubectl run -it --rm --image=ghcr.io/pdevine/thisisfine tif
or for the docker inclined:
docker run -it --rm ghcr.io/pdevine/thisisfine
… and it should look something like:
This marks a return to using
block mode in Go-AsciiSprite, and it’s the first time I’ve ever used one for
doing a doodle. The first project I did with block mode was
Text Invaders!, and I also put
together a demo for something that resembled Super Mario Bros, but I was
never really happy with the way either worked.
The biggest problem was movement. When I created Go-AsciiSprite originally I had only been thinking of ways to move normal text characters around the screen. That worked great, but with block mode we effectively doubled the resolution of the terminal. If you moved a block mode sprite, it would always move an even number of pixels around the screen. You could never move it by an odd number of pixels.
This ended up being fine for Text Invaders!, but I felt like the movement looked really jerky. For a while this seemed like a bit of a dead end. Eventually I realized I could solve the problem by introducing a new screen buffer. Instead of rendering each block of a sprite and then moving the entire sprite, I could instead delay rendering by creating a really big surface and then rendering the blocks as a whole frame.
Surfaces were an idea that I borrowed from Pygame. I’m still struggling with whether these should be a unique feature of Go-AsciiSprite, or whether I should just use Golang Images. I’m pretty torn here between using something which is a standard and used in a lot of different applications and scenarios, or crafting something which is easy to understand with only the features needed to easily render cheezy graphics in the terminal.
I guess we’ll see. This is fine, right?