I have this thing about little displays. I make the same noises when I see a small TFT or LCD module that other people make when they see kittens. I also like novelty clocks (as long as they are accurate!), coding graphical demos, and microcontrollers.
As you can imagine, if I can make a project that touches on all of these things, then that makes for a happy-me. To make it perfect, I just need to add rum …
So I’d like to make a small clock that can sit on my desk, showing the time with a variety of silly/interesting graphical effects. Normally I’d base it around the Arduino (my microcontroller of choice) but for this project I want my graphics to be a bit more impressive, enjoying a larger amount of processing power and RAM … so I have decided to use a Raspberry-Pi instead.
Thinking about code layout
If I’m writing different clock faces (which is how I will refer to the graphical effects) then I need to spend some time thinking about how to arrange the code. If I can get it right now (or “right ish“) then it saves me lots of swearing and refactoring later.
Multiple clock faces means the possibility of a lot of duplicated code – code that all (or many) faces would need. This would be bad. A better way to approach it would be to implement a framework for the clock, and think of the clock-faces as “plugins” into it.
The clock faces shouldn’t really need to know or care about the intimate details about the hardware they’re running on. They just need to know what the time is, and a standard way of presenting an image for display.
A “clock engine”
I’ve been a programmer in the computer games industry for well over twenty years, so I’m well used to the concept of an engine. So to begin this project, I need to build what I’m calling the “Clock Engine”. This is a framework which allow me to easily create new clock faces. Broadly speaking, this means we try and classify our code routines:
- Platform specific – code that is specific to the hardware it is running on. Talks to the OS, reads the time from the RTC, deals with the actual mechanism of getting images displayed, and so on. If we decide to support a new platform, this is the stuff we replace.
- Clockface specific – code that makes each clockface unique. Makes raindrops fall, fireworks explode, etc.
- Middleware – the code in-between. Useful to many clockfaces, but not specific to any face in particular. This is the code that plots sprites, draws lines, and so on. If a routine I write for a clockface could potentially be used by another clockface later on, then it should probably go in here. Code in here becomes a useful tooklkit for any clockface I make, and is key to building up a good framework for the clock.
This is a highly simplistic arrangement. In something as complicated as a ‘good’ game engine (now there’s a subjective – almost oxymoronic – phrase!) the divisions are not always this obvious. But my project will be orders of magnitude simpler, and this distinction between code areas makes for clearer design.
But to begin, that’s very much a pad-and-pencil exercise. I’ll do it in a pub, while I’m waiting for a random child to finish their evening club. Right now, the next thing I want to do is to check I can drive one of these screens with a Pi …