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:GameIndex], [Template:index_section] and [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: #FONT, #SCR, #UDG and #UDGARRAY. These macros have several numeric parameters, most of them optional, which means that their parameter strings can be unreadably long. For example:

#UDG32768,,,,,,1

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:

#UDG32768,rotate=1

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 #UDG and #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!