19 November 2018
As you might know, a new version of Scratch launches in January. This new feature has a lightly redesigned interface, with the Stage on the right (where it was for Scratch 1.4) and a new ability to scroll through all the blocks to find the one you want. The most significant change, though, is that it's been rebuilt from the ground-up using HTML5. That means the same version of Scratch can now be used across a wider range of devices, compared to the previous Flash-based version of Scratch. Raspberry Pi users will be first class citizens in the Scratch community for the first time, able to use the same online version as everyone else.
Scratch 2.0 also works on the Raspberry Pi and now features in the Raspbian download. It's noticeably slower than Scratch 1.4, though, so I was wondering how Scratch 3.0 would measure up.
I created a simple benchmark program that times how long it takes for the cat to walk back and forth across the screen in 1000 movements of 10 steps each. Using a loop of 1000 movements helps to amplify any performance lag so it's easier to measure. Here's the code:
This isn't a perfect benchmark. Some operations (in particular the graphic effects) work more slowly in some versions of Scratch, for example. Because most Scratch programs use sprite movements, this code should give a useful indicator of how they will perform, though. By creating a more complicated benchmark using more features, the risk is that it doesn't capture the typical performance and that some highly optimised (or very slow) commands create a misleading average result. This test is based on the beta as at November 2018, so the launch version of Scratch 3 may be faster or slower, and different software configurations on the devices may also change performance.
I rebuilt the test script in each version of Scratch before testing. My test hardware was:
- A Raspberry Pi 3 Model B+
- An iPad Mini 2 (ME277B/A, from 2013). For Scratch 1.4, I used the Pyonkee app with its default sprite. Pyonkee brings Scratch to the iPad but does not include the trademarked sprites.
- A Windows 8 desktop PC
Obviously, using different devices and more modern devices in the case of the PC and iPad, you may see different results. You can see the code above if you want to try it on your devices, and feel free to share your observations in the comments below.
Drumroll, please! Here are the results, with execution time shown in seconds:
|Scratch 3||Scratch 2||Scratch 1.4|
|Raspberry Pi 3||64.35||70.14||21.7|
|Windows 8 PC||33||33.32||25.27|
Performance was not always exactly the same, but it was close enough to give a fair indication.
So, the key conclusions are:
- The Raspberry Pi Foundation has invested heavily in optimising Scratch 1.4 and it shows in these results. It was the fastest of all the combinations I tested. While Scratch 3.0 will be good for simple programs, budding coders may prefer to stick with Scratch 1.4 so that their scripts and their games run faster. The Scratch 3.0 interface also runs a bit slow on the Raspberry Pi.
- On my Windows PC, Scratch 3.0 is roughly the same speed as Scratch 2.0, and a bit slower than Scratch 1.4.
- On my iPad Mini, Scratch 3.0 is very slow. The interface is pretty responsive, so you can code simple scripts okay but will probably find games are unplayably slow.
It is exciting that Scratch 3 will enable everyone to be part of the vast and growing Scratch community, running the same version of Scratch and enjoying the same features for sharing and discussing projects. There's nothing to stop anyone building their first scripts and programs using Scratch 3 on these devices. As coders progress to more advanced projects and speed-sensitive games, they may prefer to seek out a device with faster performance, depending on the device they are starting with.
UPDATE: Following a discussion on Twitter, I have new results to share:
- "Result (average of 3 runs, scratch 3 beta running inside Chrome) of the benchmark running on a Pi3-based pi-top (current Polaris) was an execution time of 69.91s, so a bit slower than a vanilla Pi3/Raspbian," says Nick Morrott.
- "Tried @vivaldibrowser with beta @scratch 3.0 on Pi3B+. A little slower than your reported figure. Had to spoof the User Agent as Scratch 3 refused to run. It ran perfectly so Vivaldi should be supported," says Albert Hickey.
- "My [Windows 8] computer gets 37.88 in scratch 1 and 33 in scratch 2," adds Ryan Walmsley.
07 November 2018
The game featured in my latest book, Mission Python, is called Escape and sees you solving puzzles to escape a space station on Mars where the air is slowly leaking away. The book advertises the game as working on the Raspberry Pi 3 and Raspberry Pi 2, and on Windows PCs, running Python 3.6. On these platforms, I was able to test both the build of the game and the play-through of the game to completion. The game should also work wherever Pygame Zero runs, but I haven't been able to test it everywhere. I set a high standard for accuracy and testing in my books, and only felt able to actively endorse the platforms we had thoroughly tested.
Some readers have been in touch to ask about compatibility and pass on their advice for other readers. Here's a round-up of compatibility tips and tweaks.
Does Escape from Mission Python work on the Mac?
Yes! Othelo Vieira has kindly provided installation instructions for the software on his blog. David Weissman has also been in touch to confirm it's working "flawlessly" on his iMac. Many thanks to Othelo and David.
Does Escape from Mission Python work on Ubuntu?
Yes! Matt, also known as RaspberryPiSpy, is using Ubuntu 18 and had previously installed Python 3.6 and Pygame. He found he had to install Pygame Zero using pip3 install pgzero. To run the game he had to use python3 -m pgzero escape.py. Ian Brown confirms this approach using pip3 to install Pygame Zero but says you may hit permission problems, and recommends sudo pip3 install pgzero in that case. If you can't use sudo because your system is locked down, you can try pip3 install pgzero --user. Many thanks to Matt and Ian for testing and sharing their discoveries.
Can you use Thonny with Mission Python?
Yes! Reader Ian Brown says that to do so, you need to put import pgzrun at the very top of the code and then add pgzrun.go() at the very end. He is using Thonny on Ubuntu. Thank you, Ian!
The book uses IDLE, and you might find it useful to stick with IDLE because the color coding will match the colors used in the book.
Does the Mission Python game Escape work with Python 2?
No, sorry. Pygame Zero is only available for Python 3. You can easily download and install Python 3. The instructions are in the book.
Does the Mission Python game Escape work with Python 3.7?
The book recommends Python 3.6 because at the time of writing, Pygame wasn't available for easy installation on Python 3.7. Charles G Smith Jr has been in touch to say he's got the game working on Python 3.7. He writes: "Good News. I was able to get your escape game up and running using version 3.7 of Python. Here is what I did to make your code work with the latest version. I added the import statement of import pgzrun at the top of the program, and I also added the statement pgzrun.go() at the bottom of your program." Many thanks to Charles.
If you're less experienced with Python and/or don't already have it installed, I still recommend using Python 3.6 as described in the book to avoid the need to add extra code into all your listings. You can download Python 3.6 here.
Does the Mission Python game Escape work on older Raspberry Pis?
It doesn't crash, but it runs too slow to enjoy. It does need a Raspberry Pi 2 or Raspberry Pi 3 really.
What screen resolution does the Escape game from Mission Python require?
The game window has a height of 800 pixels, and I have been running it on a screen with a resolution of 1152x864 or higher. However, I did a quick edit to adjust the window height to 700 pixels so it can fit on a screen with a resolution of 1024x768. You may still need to hide the taskbar. You can download the smaller version of Escape here. You will need to rename the extension from .txt to .py, or paste the code into your code editor.
The tallest room in the game is the third room you visit (West Corridor, room 37), so in this version I have taken the height down from 15 to 13 tiles, so it matches the next-largest room sizes. I have repositioned the toxic floor tiles within the new room to avoid them being too close to the bottom exit, which makes them unfairly hard to avoid. I have commented the lines that I changed in this program. Note that in the draw() function, the red box that is used to clear the game area must be resized to avoid overwriting the air and energy bars, and those bars must also be moved up in the AIR section of the program.
Thank you to Ian and Ben Brown for identifying this issue.
What about other compatibility questions?
If you have any concerns, here's a low-risk way to test it works. You can download the free PDF sampler, which includes the installation instructions for Windows and Raspberry Pi together with instructions to get the game working, and you can download the final game code too. You can then test that the game works on your computer before buying the book.
Thank you to everyone who has supported the book so far. I'm excited to see your reviews and customisations!