Matt

I polished some code and I am continually working on the new asset object that will hpefully allow me to create some interesting game mechanics in the future.

I've finished the new and improved image from file drawing function. However, I don't currently have a way to test it because I have not yet made a tool to import assets. So that's what I'll be focusing on now.

I started reworking the image drawing function, but due to some health reasons, I can't work as fast as before at the moment, so progress is rather slow at the moment. However, I still want to make at least some progress to obtain the stickers.

As a preparation for a game idea I have, I am working on a better asset management system. So far, I just have a mental map of how it should work and I have started by writing some basic documentation.

Anyway, even though I said I would give up... I had gotten an idea and managed to fix the display streaming over USB.
Yes, it is slow... (slower than I expected), BUT it works!
It still has quite a few quirks, and it could be improved in many ways, but I'll look into that later.

I give up! I made the mistake of trying to transfer data via USB again, thinking, Oh, what could go wrong? I can certainly figure it out this time! Turns out, everything can go wrong and I encountered a similarly unsolvable (or brobably the same) data corruption problem that I already encountered when I tried to move screenshots from the Pico's flash.
You can see the current state of things in the video.
(Bear in mind that this is after about two and a half hours of trying to debug it and nothing working!) As you can see, the streaming works (kind of) but because of a significant amount of data getting lost (You'd think after almost three hours I'd at least know where, BUT I DON'T!) the image shifts really horribly all over the place.
So, I've just decided to give up for now and probably focus on developing a new game instead, because this is hell, and I've lost too many hours of my life on this.

I updated the screenshot_export.py tool in the GamePico-Tools repo.
My main focus was on improving image conversion speed. By using numpy instead of a per-pixel approach, I managed to speed it up a tiny bit... From about 150 ms per image to under 2 ms per image. So that is... qite nice.

After a few painful hours of experimentation, I discovered that the GZIP algorithm is slightly faster, so I reworked the binFrame file format and I also added decompression capabilities to the screenshot_export.py tool in the GamePico-Tools repository.
Ultimately, the only benefit of implementing file compression ismuch smaller file sizes but not a much better performance while recording that I hoped for.
I also found out that when recording to the Pico instead of the SD card, and then downloading the files from the Pico to a computer, the files often get corrupted. I only observed this behaviour with compressed files, however, I was unable to pinpoint exactly what is causing the corruption, so I will have to look into this later. For now, I can only guarantee that recording only works without problems when using an SD card.
However, I now have a new feature planned that I want to experiment with, that might solve all these problems.

Also, here you can see the size difference between the same compressed and uncompresed screenshot:

So... I experimented a bit and compiled a custom MicroPython firmware only to find out that the ZLIB compression takes so long that it does not have the desired effect.
The original problem is that writing to the SD card takes around a second per frame. I had hoped that the reduction in file size achieved by compression would be significant enough to offset the data writing time. But, in the end it turned out that although the files were about 10x smaller (about 11 kB instead of around 110 kB), the compression takes so long that the difference of total time per frame is basically zero... So - at the moment, my plan is to try to create my own fast compression algorithm. And if even that does not improve the current situation, I will have to resort to something that I don't want to reveal yet, because I plan to do it no matter what the result of my attempts is and I hope it will be as cool as I imagine xD.
Also don't mind the syntax highlighting. I did not set up VS code to handle the custom firmware.

So, after a while, I'm finally posting a devlog! I've just finished polishing some bugs, but mainly I implemented a new screen recording system and a new .binFrame file format.
The documentation for this format can be found on my GitHub in the GamePico-Tools repo. The only remainig thing to implement when it comes to recording is file compression.
However, to do that, I'll have to compile my own firmware version. So, I believe now is a good time to reship this project again with a new game and a good recording system that will get even better with the next ship.

So... I finally finished the 2048 game! Or... At least I got it into a state where I'm finally pretty satisfied with it. It has good animations, a win screen for when the player achieves the 2048 number, and also a game over screen for when the player fills up the grid and loses.
I will now look into polishing things up and I also plan to rewrite the screen recording code.

I've added a new game!
Well... At least the concept of it and really basic gameplay. It's 2048!
The code is a bit of a mess and I still have to add score tracking, and the conditions for winning or losing the game. Currently the game just gets stuck if the player loses.

After getting sidetracked by a separate project that I ultimately postponed for now, I am working on a new game!
Now, I don't have much progress to show yet, other than a few tweaks and some useful new functions. However, I do have one new and very useful function to show. (look at the image) I know — it's so revolutionary that you probably didn't even notice it! Try looking closer...
Okay, you probably still don't see it... Just look at the main menu title, it has rounded corners!! That's right — I added a function that can draw rectangles with rounded corners. I plan to use it for the new game, but it can also be useful elsewhere. Like... Imagine... Rounded buttons!
Anyway, I'm getting sidetracked again. I'll now get back to work.

I also thought I would post an alternative setup to the one that I posted originally. This one is much more compact and only requires the Pico and the display to be connected together. However, it requires powering by USB and also can't record the screen to an SD card.

I fixed the bug with the buttons not centering properly in the horizontal scrolling menu.

So, I finally added a difficulty selector to the snake game. With that I fixed a few bugs as well (for example in the vertical scrolling menu, where the selected button did not render as selected if it was selected by the joystick center button).
I also realized that I forgot to put out a devlog about adding a horizontal scrolling menu function that I added and it is used for example for the difficulty selection.
However there is still a bug that causes the buttons not to center correctly.

I just added a How to run section to README

I completely refactored the snake game and removed redundant code.

I fixed the snek game that I broke when adding the multiline text support and I added a cooler game over screen.

I spent some more time refining the code and I added multiline text support which allows me to do stuff like this very easily:
(It should also work seamlessly with any other functions like buttons or titles.)

I just added a simple controls tutorial/walkthrough and now I am ready to ship.

(Once again, note that all the screen captures from the Pi Pico are upscaled from 240*240 to 960*960 resolution in all my devlogs.)

I just finalized readme and I am working on uploading a video of the working project. Once I'm done, I'm ready to ship.

I added a brightness setting. (the effects of which are not visible on the recording but trust me, it works)
I also managed to seamlessly integrate it with the scrolling menu such that for the user it seems like they have not left the menu.

I just updated the behaviour of the scrolling menu when the A, B, X or Y buttons are pressed.

I added a scrolling menu function. Now there can literally be an unlimited amount of options in one menu. (granted as long as the fit into the rather limited RAM of the pico)
Now I only need to add a brightness and difficulty option and I think I'll be ready to ship this project.

I reworked how buttons are created and rendered into a class structure.

I fixed the image displaying function and also fixed all the image assets. I also added much better functions to record the display.

I've finally fixed the problem with color conversion and I added some minor features.
I now have to fix the image loading function.

So after three painful hours and almost designing my own tool to export images to the pico I discovered that the problem was partially me and partially in the fact that there probably is a bug in the micropython framebuf library.
Specifically in the way it processes RGB565 colors. In the image below you can see that I am setting the pixel 0, 0 to the color code #F800 which in the RGB565 color space corresponds to red.
However as you can see in the console the data written to the bytearray is actually #00F8 which is in fact not #F800 as one would expect. This, I believe is caused by the fact that the library treats the second byte as the higher byte when it should be the other way around.
All this now means that I will have to come up with a new color conversion function that works around this and also I will have to fix the new function that displays images from files.

I refactored the main menu code and I added a logo to the main menu. I also added a function to load and display images while restricting the amount of RAM used. There are however still some issues with this function. I will have to figure out why and how to fix them.

I now also fixed the screen recording feature. Each time a recording is started, new folder is created for it. This was broken because I implemented it only halfway but it should work well now.

I finally ported my own version of the snake game from my old project! Here is a little showcase of it: (Note that it is again upscaled from the original 240*240 resolution.)

I came up with a way to prevent most of the unwanted multi-clicks that are caused by the low quality buttons of the display.

I added better key press handling using IRQ interrupts in order to fix the issue where some key presses were not registered.
I have also discovered that the joystick button on the display that I chose tends to multiple-click. I will try to rectify this in the software in the future.

Since Each devlog allows for only one image, I am posting this one to show off the screenshot exporting tool itself as well.
I also fixed the file number selector in the screenshot export tool.

I can finally export animations!
I have finished a tool to export images on the PICO in multiple formats, including GIF. Now, I will focus on adding proper configuration files and settings menu.

I have added a screenshot function. I will have to implement it properly now in order to allow for recording as well. And I also added the possibility to save the screenshots to an SD card.
Now, I will focus on creating a proper tool to export those screenshots and I will try to add the posibility to record GIFs.
(The screenshot here is upscaled from the original 240*240 size)

So, after more than 7 hours of work this is my first devlog. I've started refactoring my old code and so far the main menu is mostly done. I have also made a new logo for this project of mine. Now I'll work on actually adding some basic settings and rewriting my old snake game to make it compatible with this new version of the code.