Kruci: Post-Mortem of a UI Library

Summary

I love doing experiments - side projects to my side projects, for fun or out of necessity. Sometimes those experiments and end up in something useful, other times - not so much. Let me tell you about one of the latter projects - about terminals, user interfaces, and trade-offs. My programming spare time is dedicated mostly towards kartoffels, a game of mine where you're implementing firmwares for tiny robots: Main menu of the upcoming kartoffels v0.8. For the next version I've started to work on a new challenge, a map where your bot is stranded on an island - as the player, you have to implement a bot that collects some nearby rocks and arranges them into a HELP ME text: An island in the middle of an ocean -- if only you squeeze your eyes a bit and assume that the gray dots are, in fact, sand; this is work-in-progress, so you have to picture rocks as well. Since ocean is rarely stationary, I thought it'd be nice to add waves as a visual gimmick - inspired by a shader, I went with: Waves, slowly waving around. ... then I ran htop and saw that damn, those wave calculations are heavy! For each ocean tile you have to calculate a couple of sines and exponentials - it's not the end of the world for a modern CPU, but it does become problematic in my case, because the game is rendered entirely on the server, players are just SSH terminals. So it's actually a couple of sines and exponentials for each pixel, for each frame, for each player. Fortunately, eyes can be easily fooled. Even though the ocean seems alive, it's not like the entire ocean changes between every two consecutive frames - so, intuitively, we shouldn't be forced to recalculate everything from scratch all the time. This is not a novel thought - games have been amortizing calculations across frames for years now, for better or for worse. Eventually I've been able to get an acceptable frame time by keeping a buffer that's updated both less frequently than the main frame rate and merely stochastically - and this...