06/21/2019 at 15:53 •
The SAMD21 powering the µGame consoles is not a daemon of speed. With 48MHz clock and software floating point operations, not to mention the overhead from CircuitPython interpreter, it's barely enough for a dozen frames per second in a relatively simple game. But there is good news: a recently released beta version of CircuitPython, 4.1.0, has enabled an optimization option which has been so far disabled to save on firmware size. It had been re-enabled, because it turns out that it provides a five time speedup of the CircuitPython virtual machine, and the size savings weren't that big anyways.
So now suddenly all µGames are going to be 5x faster as soon as you upgrade their firmware with 4.1.0 that you can download from http://circuitpython.org.
06/06/2019 at 19:57 •
Yesterday I received the order for the last µGame on Tindie. That makes it 111 units sold on Tindie (and maybe a dozen more sold elsewhere). Since I don't plan on making any more of them, that was the last µGame being sold.
The project is not finished, of course — I will continue to improve the firmware, and I want to write a few more games for it. I won't be making promises, though — reality has a way of getting into my plans.
If you want to try developing such games with CircuitPython yourself, you can now get the PyBadge board from Adafruit — apart from a slightly bigger screen and much more powerful MCU, it's compatible, so all the games should work on it.
I have certainly learned a lot with this project, and I hope there will still grow a community of users for it.
05/20/2019 at 20:43 •
The CircuitPython 4.0.0 has just been released, and it does include support for µGame. However, due to last-minute breaking changes in RC4, and my travelling that made it impossible to fix it over the weekend in time for the release, the Stage library is broken in that release and won't work.
So please refrain from upgrading for now.
I'm being told that there should be a version 4.0.1 released next week or so, which will have it all fixed.
04/19/2019 at 19:07 •
I finally worked on an improvement that I long wanted to do to the _stage library, which is at the heart of µGame: make the communication with the display asynchronous by using DMA. This way I can have two buffers, and calculate the contents of one of them while the other one is being sent to the display.
As a test I used the balls demo from the tutorial, but with all waiting for the next frame removed — so they move as fast as they can.
Here is how it works before DMA:
And here is how it works with DMA:
As you can see, there is barely any perceptible difference at all!
The code I wrote for this is pretty nasty and hacky, and after seeing this, I don't think I have the heart to clean it up and send it as a pull request — it's simply not worth it.
However, I will keep an eye for other ways of improving the firmware.
UPDATE: Yes, I made some more precise measurements as well. Running through 1000 frames of the animation took the DMA version 31.034s and the non-DMA version 32.699s. That is 32.22 fps with DMA and 30.58 fps without.
UPDATE2: I did a second test, with full-screen updates this time. 159.08s for non-DMA, versus 148.708s for DMA. That's 6.28 fps versus 6.72 fps. Even with such a large amount of data, the difference is negligible compared to the time spent computing it.
04/11/2019 at 23:12 •
The upcoming CircuitPython 4.0 introduces, among other things, built-in support for displays. That means that when there is an error in your code, you will be able to see it right there on the screen, without having to connect to some gnarly serial ports. For now the built-in display code is slow — fast enough for displaying text, but not for games. So I went and modified my #Stage, a Tile and Sprite Engine library to coexist with the displayio support, to get the best of both world — console using displayio, and fast updates using stage.
There are still some tweaks left to do, perhaps use of a smaller font, and I still need to resolve the audioio problems that appeared with CircuitPython 3.0, but there are already nice improvements.
I also hope to see if I can use DMA to speed up display updates considerably.
09/30/2018 at 10:21 •
CircuitPython 3.2.0 has been released a while ago, and brings a lot of bug fixes and some performance improvements. It would be nice to use it for µGame. Unfortunately, it also had some changes in how audio is handled, and since that interacted with available memory in ways that made the example games not work, it required more work on my part than just rebasing the repository.
However, I managed to work around the problems, and a new version of the firmware is now available at https://github.com/python-ugame/circuitpython/releases/tag/ugame10-3.2.0. There is also a release of the Vacuum Invaders game specially updated for that version of firmware: https://github.com/python-ugame/vacuum-invaders/releases/tag/3.2.0. The other example games, as well as the tutorial, should work without any changes.
In order to upgrade your device, you need to download the .uf2 file, and copy it to the TRINKETBOOT disk that appears when you press the "reset" button (located next to the direction buttons) twice. Once the file is copied, the device will reboot with the new firmware in place.
- 06/21/2018 at 20:40 • 0 comments
05/28/2018 at 07:28 •
After working on research and design for the #µGame Turbo for several months, and after Adafruit has started to work on their own version of a game console for CircuitPython, I decided that the improvements are not really worth the extra price and work, and decided to come back and focus on regular µGame more.
There will be no more hardware iterations (except perhaps a small update changing the USB port to one that is more friendly to the fabricators), but there is still a lot that can be done in firmware and in the libraries. In particular, I have some ideas that I want to try to speed up the screen updates and to make more memory available for the games.
The CircuitPython 3.0 is coming, Beta0 version was just released last week, and I've been working a little bit to make sure that all the libraries for µGame work with it. Right now I'm struggling with a change in the API for AudioIO, which makes CircuitPython try to allocate an extra 512 bytes of RAM every time you try to play a sound. Obviously that fails randomly in any larger game, as there is simply no room for it. But I'm sure a solution can be found — in the worst case, I will switch to a different way of making sounds.
04/30/2018 at 15:09 •
The freshly assembled µGames arrived straight from @Makerfabs and you can again get them from Tindie — there is a link at the top of this page. I will also take a few to #Hackaday | Belgrade 2018 — you can let me know in advance if you want to save on the shipping costs. I am not sure yet what other meetups I will attend (Makerfaire Prague is a possibility, and Europython is pretty much settled).
04/02/2018 at 13:01 •
I didn't mention this yet here, but I have started work on an improved (and more expensive) version of this device. I the good old style of 80s, I decided to call it #µGame Turbo (if there is going to be a third version, it will be Super µGame Turbo, of course). I'm still researching most things, but the goal is to mostly have a physically bigger screen (same resolution), more memory and better audio (better speaker, volume control, headphone jack). It should be software-compatible with the current µGame, though.
I am not sure how that project will go, and whether I will be selling that new version of the device too — there are currently simply too many variables.