03/23/2018 at 18:37 •
I just asked @Makerfabs for a quote on a new batch of µGames to be produced, and if everything goes well, they will be in stock in a couple of weeks. Also, the 3.0 version of CircuitPython is coming soon, and there will be a firmware update. The new version has greatly improved memory management, so it should help a little. I also fixed a few small bugs, and I plan to finally add the build-in art assets, which should also help with memory somewhat.
In the meantime, I started to work on #µGame Turbo, and I entered it in the Hackaday Prize. I am not yet entirely sure where I will take this project, the only thing I'm certain of is that I want to keep it compatible with the current µGame — so that all the people who bought it are not left with an obsolete device. The new version will have more memory, so hopefully you won't need to pre-compile your files anymore, and I want to try and make it have proper audio, with volume control and headphone jack, a physically bigger display, and better connectors for external stuff. It will probably be more expensive, too, so it's more like an alternative to µGame coexisting with it side-by-side rather than a replacement.
Finally, I just started today some sketches for another handheld, a #CircuitPython Game Badge, which is supposed to be even more minimal than µGame. The goal here is to minimize the price and power consumption, so that it could be used as a conference badge, given out to all participants. It's not going to be compatible with µGame, though.
02/24/2018 at 14:43 •
The SAMD21 chip is great for its native USB and the way you can just copy files on it, but since it's relatively new, the development boards for it are rather pricey. Plus, it really has small RAM and slow SPI, which limits what kind of games you can make.
For making your own µGame clone, the ESP8266 could be a much better choice. 90kB of RAM and 40MHz SPI communication with the display (the esp can do 80MHz, but the display can't) make it a perfect solution. The only problem is a somewhat convoluted way of getting files on it, using external tools, but I might be able to do something about that with #ESP8266 Dev Board with True USB if I'm lucky. So I set out to try the µGame software on the ESP8266.
The first try was using the CircuitPython firmware for Adafruit HUZZAH. Since the original µGame runs CircuitPython. Unfortunately, turns out that the HUZZAH board has been a little bit neglected, and some things don't work as expected with the current version. In particular, I couldn't get SPI to work while also using GPIO12 as D/C pin. After some failed attempts at fixing it quickly, I decided to try the good old MicroPython again.
To do that, however, I had to port my _stage tile and and sprite engine to MicroPython from CircuitPython. While the two versions are very similar to the user, they differ substantially in their internal file organization, so I spent a whole night on this. But the result is very good:
I'm using a new version of the #D1 Mini X-Pad Shield here, and a standard ST7735 breakout module. The picture on the screen doesn't look good, because of lighting — sorry about that, I don't have access to a better environment at the moment.
In any case, the Jumper Wire game seems to be working very well. The modified MicroPython sources are available at https://github.com/deshipu/micropython/tree/stage so you can give it a go yourself!
02/22/2018 at 20:56 •
While several people are working on 3D-printed cases for the µGame, @davedarko is the first to deliver! He designed a minimalist case that covers the battery on the back, but leaves the PCB exposed for perusal. Since his µGame already had a battery attached, he sent the design to Szymon Jakubiak for printing and testing. When all was confirmed working, he printed two of them in colors matching the prototypes, and sent them to me:
They look pretty slick, if I can say so myself!
02/11/2018 at 19:54 •
It took less than two weeks, and all the µGames 10 are sold. I am both a bit surprised with how fast it went, and very grateful to everyone who bought one (a lot of them went to my friends). I don't plan on making any more of them for the next few weeks, at least until the Lunar New Year ends. I am now focusing on support of the devices that have their new owners, and on updating the firmware.
Speaking of support, I already got some really valuable feedback. @Frank Buss seems to have a knack for finding all the rough edges, and his suggestions already improved the documentation and resulted in some ideas about improving the firmware. Jell also reported some issues, which have been added to the docs. I expect to receive even more feedback as the devices arrive and their owners start experimenting with them seriously.
I'm also going to work on making an emulator for this device — even if it's not going to emulate all of its limitations, it should allow easier development and debugging. You will still need to test against a real device to make sure that there is enough memory and that the speed is acceptable, though — it's not going to be a "real" emulator, just a version of the Stage library that runs on regular Python.
02/09/2018 at 20:24 •
I've been asked about the dimensions of µGame 10, hole sizes and placement, etc. — so I decided to sit down and update the OpenSCAD model that I made some time ago for µGame 6. I have put it in the repository at https://github.com/python-ugame/ugame-10-hardware
You should be able to import it into most 3D modelling software, and from there you can use it to design cases and all sort of other things.
02/05/2018 at 21:15 •
nGame (nano-game) is the tiny little brother of µGame that I made just to see if I can do it. It's a little bit bigger than an inch on a side. I got the hardware working, but I didn't have any program to test it with, since all the games I've written so far were too big to fit on the chip's flash (unlike µGame, nGame doesn't have a separate flash chip for the filesystem). When I was picking the projects to send to FOSDEM to be shown at the MicroPython table, I thought I could include nGame, and I realized that the bouncing ball demo that I added recently should fit just fine. So I quickly uploaded that, and it worked out of the box, except for the wrong colors (RGB vs. BGR) and different screen size (160×80 instead of 128×128). But I didn't have time to fix it, so I sent it like that.
Today evening I finally had some time to sit down and do it properly — I just needed to fix the display driver, and fix the code where I hard-coded the screen size.
01/31/2018 at 18:13 •
Today the package from China arrived: 50 shiny new devices. There was a small number of faulty ones that failed testing — it turned out to be a bad speaker, which fortunately was easily replaced. One board didn't flash at all — that turned out to be a faulty reset button. This one I didn't fix, but instead I will be using it as the demo unit (because during troubleshooting I had to de-solder some parts, and it doesn't look brand-new anymore).
In any case, if you are interested, the Tindie link is here: https://www.tindie.com/products/deshipu/game-10-game-console-kit/
I would also greatly appreciate if you could spread the word!
01/28/2018 at 19:32 •
I finally finished writing the bouncing ball tutorial, and published the documentation. You can see it at http://ugame.readthedocs.io/en/latest/tutorial.html
It merely scratches the surface — I will need more documentation, in particular, I will need topic guides explaining some of the most useful techniques for writing the games. But this is at least a start.
01/27/2018 at 00:20 •
I created a product page on Tindie already, for now it has 0 stock, but at least you can add it to your wishlist: https://www.tindie.com/products/11372/.
I also went and cleaned up the repositories a little bit. All relevant repositories now live under a single organization at https://github.com/python-ugame. I also separated the final µGame 10 designs from all the other prototypes, so you can easily find all the information in one place, and not wonder which parts of it are obsolete.
01/25/2018 at 20:24 •
I started adding some code examples for the documentation. The simplest sprite demo there can be is the bouncing ball. I took some liberties in making the graphics look a little bit like something familiar:
Then I added two more balls, and the final code looks something like this:---------- more ----------
import ugame import stage class Ball(stage.Sprite): def __init__(self, x, y): super().__init__(bank, 1, x, y) self.dx = 2 self.dy = 1 def update(self): super().update() self.set_frame((self.frame) % 4 + 1) self.move(self.x + self.dx, self.y + self.dy) if not 0 <= self.x < 128 - 16: self.dx = -self.dx if not 0 < self.y < 112: self.dy = -self.dy bank = stage.Bank.from_bmp16("ball.bmp") background = stage.Grid(bank) text = stage.Text(12, 1) text.move(16, 60) text.text("Hello world!") ball1 = Ball(64, 0) ball2 = Ball(0, 76) ball3 = Ball(111, 64) game = stage.Stage(ugame.display, 12) sprites = [ball1, ball2, ball3] game.layers = [text, ball1, ball2, ball3, background] game.render_block() while True: for sprite in sprites: sprite.update() game.render_sprites(sprites) game.tick()