Rock around the clock June 14th, 2014
Pyskool 1.1.2 has been released. As usual, copies are available from the download page in the shape of tarballs, zip files, DEB packages and RPM packages. Alternatively, if you’d like 1.1.2 to be served up to you by means of a package repository, you can get it from PyPI.
1.1.2 is a minor update to 1.1.1: no bug fixes or new features can be found in this release. Why bother with it, then? Well, one thing that the skool game ‘remixes’ included with Pyskool – namely Skool Daze Take Too, Ezad Looks, and Back to Skool Daze – have long been missing is their own tunes. Up till now, they have unashamedly borrowed the existing tunes from the original skool games – namely Skool Daze and Back to Skool. In 1.1.2, however, the remixes have had a musical overhaul: each one has its own theme tune, its own ‘all shields’ tunes, its own ‘open safe’ tune, and its own ‘up a year’ tune. That’s 12 (twelve) new tunes in total.
Now, I do understand that a customisation like this may be a little disconcerting at first. But note that I have taken great care to produce the 12 new tunes (actually nursery rhymes and other traditional songs) in the same style as the original skool tunes, so at least we still hear the familiar rasping notes of old. (Thanks, by the way, to Alex for showing me how to read piano sheet music.) The first person to correctly identify all 12 tunes will get, er, recognition for being the first person to correctly identify all 12 tunes!
If all this musical freshness is not to your taste, don’t despair. I’ve also customised the lesson questions and answers for each teacher in Skool Daze Take Too, Ezad Looks, and Back to Skool Daze. So if you’ve grown tired of Mr Rockitt constantly banging on about chemical symbols and animal homes, fire up Pyskool 1.1.2 today for some refreshingly different science (and geography, and history, and maths) quizzes.
Template me happy May 25th, 2014
SkoolKit 4.0 has been released. In keeping with age-old tradition, copies of this major new version are available in various formats from the download page. And in keeping with more recent tradition, you can also obtain this major new version from PyPI or the PPA.
The numerically minded among you might have noticed that 4.0 is a whole major version number up from 3.7, the previous release. (For the benefit of the innumerate among you, I hinted at this with the phrase “major new version” – twice – in the first paragraph. You are welcome.) Why 4.0 instead of 3.8? Mainly because there have been some changes that make SkoolKit 4.0 incompatible with skool files, ref files, control files, skool file templates and CSS files that work with SkoolKit 3.7 and earlier versions. For example: the
[Info] section of the ref file is no longer supported; the ‘z’ and ‘Z’ directives, which were deprecated in 3.7, are no longer supported; and the class attributes of many HTML elements have changed, which means your custom CSS files may need some modification to make them work with 4.0. See the documentation on migrating from SkoolKit 3 for a comprehensive list of the compatibility-breaking changes, and for information on the
skoolkit3to4.py utility, which might ease some of the pain of switching to SkoolKit 4.
So much for the incompatibilities. What of the new features? The biggest one is the introduction of HTML templates, from which every page in an HTML disassembly is built. No longer is the format of the HTML produced by
skool2html.py determined by code buried inside the skoolkit package; now you, the format-conscious user, are in control. Don’t care much for the layout of the disassembly index page? Then create your own
[Template:index_section_item] sections in the ref file. Need HTML5 for some pages instead of the default XHTML 1.0? Simply tweak the relevant
[Template:*] sections, and away you go.
The next new feature on the list is support for keyword arguments in the image macros:
#UDGARRAY. These macros have several numeric parameters, most of them optional, which means that their parameter strings can be unreadably long. For example:
Any idea what parameter the value
1 corresponds to here? If not, take comfort in the fact that this macro can now be written more clearly thus:
Also new in the realm of image creation is support for AND-OR masks. In previous versions, SkoolKit has assumed that sprite mask data is used as follows: take a background byte, OR on the sprite byte, and then AND on the mask byte. I refer to this masking scheme – which is used by Skool Daze, Back to Skool and Contact Sam Cruise – as OR-AND masking. However, it turns out that some games use mask data the other way round: take a background byte, AND on the mask byte, and then OR on the sprite byte. If you’ve had trouble producing masked images, it may be because AND-OR masking is required instead of OR-AND masking. If so, the new
mask parameter of the
#UDGARRAY macros should fix the problem: use
mask=2 to specify AND-OR masks.
That’s about it for the main new features; see the changelog for further details. Be brave and upgrade to SkoolKit 4.0 today, and be sure to report any bugs you find, or incompatibilities I haven’t documented!
Bases and spaces March 8th, 2014
SkoolKit 3.7 has been released. As usual, copies of this release are available, in various formats, from the download page. If, however, the idea of downloading SkoolKit from this site repels or offends you, you can install it via PyPI or the PPA instead. The choice is yours.
The last release to get an announcement on this here website was version 3.5 over six months ago, so I should probably go over a few of the changes that have taken place since then. For the image-creating fans among you, the big news is that the
#UDGARRAY macro is now capable of building animated images from an arbitrary sequence of frames (each of which is built using a special form of the macro). SkoolKit has had support for building animated images that contain flashing cells since 3.0.1, but the new, enhanced
#UDGARRAY macro enables you to be a bit cleverer and produce animated sprite images such as the ones of Miner Willy in the incomplete Manic Miner disassembly.
On the subject of disassemblies, a new one has joined the examples distributed with SkoolKit: the incomplete Spectrum ROM disassembly. It was made possible in part by the (new) support for disassemblies with a start address below 10000, and sits proudly alongside the incomplete Jet Set Willy disassembly and the aforementioned Manic Miner disassembly. In addition, built versions of these example disassemblies are now published online (as you may have gathered).
In the number bases department, SkoolKit now supports binary numbers in DEFB, DEFM, DEFS and DEFW statements. That is, they can be parsed in skool files for the purpose of building a snapshot (as demonstrated by the character set in the incomplete Spectrum ROM disassembly), and can be preserved in and restored from control files and skool file templates. The base of decimal and hexadecimal values can be preserved too by using the new
--preserve-base option of
Finally, on the control directive front, the ‘z’ and ‘Z’ (zero) directives have been deprecated in favour of the new ‘s’ and ‘S’ (space) directives, which can encode DEFS statements with non-zero byte values (e.g. ‘DEFS 8,255′) – something that was not possible with the old ‘Z’ directive. Now that the ‘s’ and ‘S’ directives are here, I really do wonder how we ever did without them.
As ever, more details on the changes since 3.5 can be found in the changelog. Here’s hoping they keep you going until 3.8 arrives!