All of the games I have written to date for embedded systems such as Breadboard Games and badges featured a uniform background which was usually black. This was simple to implement . If a character is to be moved, it is first overwritten with the background colour and then redrawn at a new location. More complex backgrounds that featured terrain such as grass or rock were not so easy to deal with. In a desktop programming environment I would probably tackle the problem as follows:
(1) Make a copy of the area that the character will obscure
(2) Draw the character
If a character is then to be moved, you simply write the copy of the obscured area to the screen to hide the character and then repeat the process at a new location.
Step (1) requires a readable display buffer. The ST7789 in this project is a write-only device. In theory I could make a frame buffer big enough to hold the entire screen and then repeatedly write this out over the SPI interface. The display has 240×240 pixels, each pixel encoded in 16 bits. A complete framebuffer for this requires 240x240x2 = 115200 bytes. The NRF52833 MCU driving the display has 128kB of RAM so not much would be left over for stack and variables. Dividing the display up into “tiles” can greatly reduce the RAM requirements.
Let’s divide the screen up into 30×30 pixel tiles. This may seem a little large however the ST7789 screen is very small and has a high pixel density. A 30×30 tile represents an area of 3mm x 3mm approx within which a texture or character is drawn. Let’s also use the following two tiles:
The left tile represents a character in a game (surrounded by transparency), the right one represents grass on the ground. We can completely fill the screen with 64 grass tiles. When our character moves across this background it can cover (at least partially) at most 4 grass tiles. This means that we can make use of a framebuffer in RAM that is 2 tiles x 2 tiles or 60x60x2 bytes in size (7200 bytes). We can move the character across the framebuffer in RAM and then write the framebuffer to the display. If the character moves beyond the edge of the framebuffer we can move where we write the framebuffer to the display and adjust the character’s position within the framebuffer. The image below shows how the framebuffer moves when the character moves diagonally across the screen (the background was not drawn to emphasize the movement).
The character moves across screen as shown in the following video:
https://youtube.com/shorts/gbuUdUqhvyA?feature=share
As can be seen, the movement is smooth and quite fast (it is actually artificially slowed down). There is however a problem: The bounding square of the character is drawn as white which overwrites the background. It would be much better if the background bounding rectangle for the character was treated as transparent.
A slight detour for PNG files.
I’m using KolourPaint in KDE (Kubuntu) to produce the tiles. These images are saved as PNG files with 4 channels: Red, Green, Blue and Alpha. The Alpha channel represents the transparency of a pixel. In this case I’m concerned with two levels of this: completely opaque (Alpha=255) and completely transparent (Alpha = 0). These PNG files are converted to C header files which encode the RGB values into a 16 bit colour value suitable for use with the ST7789. As mentioned in a previous blog post, the ST7789 uses 565 (RGB) encoding. A value of 11111 111111 11111 represents white. A slightly different value of 11111 111110 11111 (the LSB of the green channel is set to 0) looks nearly the same on the screen. I decided that the colour value of 11111 111111 11111 (65535) would represent “transparent” while any value that was meant to be white would be re-encoded as 11111 111110 11111 (65503). The following python script was then used to convert the png file to a C header file.
# Want to deal with transparency. Need to nominate a particular colour as "transparent"
# Going to go with 0xffff as being transparent
# if a pixel is designed to be this colour it will be changed to
# 0b11111 111110 11111
# i.e. the least significant green bit will be set to 0. This is slightly off the intended white
# but not by much.
import sys
Filename=sys.argv[1]
Forename=Filename.split(".")[0]
from PIL import Image
img=Image.open(Filename)
width, height = img.size
pixels = list(img.getdata())
print("#define ",end="")
print(Forename,end="")
print("_width ",end="")
print(width)
print("#define ",end="")
print(Forename,end="")
print("_height ",end="")
print(height)
print("static const uint16_t ",end="")
print(Forename,end="")
print("[]={")
for x in range(0,width):
for y in range (0, height):
(Red,Green,Blue,Alpha) = pixels[(x*height)+y]
# Colour format : Red : 5 bits, Green 6 bits, Blue 5 bits
# Assuming all components are in range 0 - 255
if (Alpha == 255):
Red = Red >> 3 # discard 3 bits
Blue = Blue >> 3 # discard 3 bits
Green = Green >> 2 # discard 2 bits
st7789_16 = (Red << 11) + (Green << 5) + Blue
low_byte = st7789_16 & 0xff
# have to do an endian swap
high_byte = st7789_16 >> 8
st7789_16 = (low_byte << 8) + high_byte
if (st7789_16 == 0xffff):
st7789_16 = 0b1111111111011111
print(st7789_16, end="")
else:
print("65535", end="")
print(",")
print("};")
The framebuffer output functions were adapted to take this special transparent colour into account and the new motion now looks like this:
https://youtube.com/shorts/Vsr7n7rsNRI?feature=share
Once again, motion looks smooth (and has been artificially slowed down).
Code for all of this is in quite an untidy state for now but will be uploaded to github over the next couple of weeks
ioprog 