LowRezJam Day 1 - Going Off Track

August 2, 2023 | Tags: programming gamedev lowrezjam

LOWREZJAM 2023 started today! It’s a game jam for making a game with a maximum resolution of 64x64. I’ve participated in it before, with my game Enchanted Gemstones in 2020, and I want to do it again this year.

Getting started on the first day, I may have gone a little tiny bit off track… I maybe accidentally created a drawing applicaiton instead of a game. But that’s OK! I can work with this! Making a 64x64 drawing app will be a fun project! :abunhdhappyhop: ⁠

The jam is 2 weeks long, and this is only the first day, so if I want to pivot to something more of a game, there will still be plenty of time to do that.

What I Have So Far #

The video starts with a all of the code I have so far, then moves on to the demo. As you can see, I have a working mouse cursor, and you can draw. You can cycle between colors with RMB, and you can draw by holding LMB and moving the mouse. Pressing MMB clears the drawing. I drew a little kitty to show it off :true: !

Edit: The source code for my project is available here: :github: Rayquaza01/pico-draw

General Goals #

Here’s a couple general goals that I’d like to accomplish for this project before reaching the deadline

Tools #

I’d like to have different tools for drawing. Right now, it just draws a single pixel where the cursor is. I’d like to have a couple different tools to use, including:

Line
Fill
Circle
Square
Star (maybe?)
Stickers (pasting pre-made sprites onto the field)

I’d like to have a menu that can be opened (maybe with O or X? maybe middle click, and change clear to O or X?) that shows all of the different tools and colors, and lets you switch between them by clicking them. Switching between colors with a menu is very important IMO, because it’s annoying cycle through them, and then find you missed the one you want.

Game Integration #

I’d like to have some sort of game / minigame you can play with the image editor. Maybe something kinda like Drawn To Life; A simple platformer where the player can draw a platform and use it to make it through a level? Maybe let the player draw the sprites used for the player, enemies, pickups?

Saving and Loading #

PICO-8 has persistant storage, in the form of cartdata, dget, and dset. Do we have enough space to store an image? Let’s do some math. Numbers in PICO-8 are 32 bits (4 bytes) long. They are stored as 16:16 fixed point numbers. We have 64 numbers in cartdata (or $64 \times 4 = 256$ bytes).

Currently, I store the field in a 2 dimensional, 64 by 64 array. That’s $64 \times 64 = 4096$ numbers ($4096 \times 4 = 16$ KiB) to store our display in memory. Obviously, that’s too much for cartdata. 16 KiB is, of course, much larger than 256 bytes. However, I’m storing things in memory very inefficiently. PICO-8 only has 16 colors, so for each in number in our display, we only need 4 bits! This means we can store $\frac{32}{4} = 8$ 4-bit numbers in each 32-bit number! If we packed our memory correctly, we would actually only need $\frac{16384}{8} = 2$ KiB to store our display. That’s still 8 times too large… You might think this is unsolvable, but you’d be wrong! :blobfoxthinkanime: ⁠

PICO-8 also provides us with GPIO pins. This lets us communicate externally (with actual GPIO pins on a Raspberry Pi, or with JavaScript elsewhere). We have 128 bytes of shared memory between JavaScript and PICO-8. That’s not much, but we should be able to dump the display in chunks and read them in JS. And once we have them in JS, we don’t have any storage constraints anymore. We can just toss however much data we want in localStorage and call it a day! We can also do the reverse, and load the localStorage data back into PICO-8 through the GPIO pins. This would let us save and load drawings of any size, without caring about PICO-8’s cartdata constraints.