Wednesday 17 January 2024

Multipaint and ZX Spectrum Next

Some development notes about ZX Spectrum Next graphics modes in Multipaint, the multi-platform (Linux, Mac, PC) for creating 8/16 bit images.

The supported screenmodes are "layer 2" graphics, 256 x 192, or 320 x 256, both with 256 colors. ZX Next has many more modes, but these look like the most prominent for graphics and games.

I know it's possible to write code that displays 512 colors on-screen, but as usual, Multipaint only supports the most vanilla screenmodes.

Paint programs for 256 color modes are common, so I tried to compensate by adding a bunch of useful load/save options, more than the usual amount.

DK sprites from the Next SD card

Why are the formats individually listed in the menu, and not just integrated in the file selector? Well, I've found that if a feature is not very visible, people tend to think it does not exist.

Seriously though, one day I may add a better file extension recognition for the main file selector too.

Multipaint was designed for about 16 colors in mind, so the palette and color options for 256 color modes can appear a little limited.

At least the FX brush modes such as Lighten/Darken, Tint and Mix help somewhat and work better in 256 colors than in other modes. I still consider these as somewhat "beta". But you can draw a filled rectangle with the FX "Darken" on the desired area to make it more subdued, without having to pixel everything again or alter the palette.

Spectrum Next has a convention where the default palette holds a 256-color "8-bit RGB palette", 8 steps for Red, Green and 4 steps for Blue. 

This is especially useful for NextBASIC, you can work ideas without having to define palettes. The 256-color set is already very comprehensive – there isn't that much more you can do with the 512 color range. (8 greyscales is something that springs into mind, though.)

Next default "8-bit" palette

Multipaint respects this default palette convention, so if you import a PNG image, the palette is not altered.

This behavior can be changed from File->Settings, by turning on the "re-palette" option for incoming files.

Coders: Each platform specific Save menu option can be invoked from the File-> Export TXT item. From this dialogue you can save text/source versions of the same formats. These can then be copied to or included in an assembler source.

As of now the result is a little unresponsive, but the file ought to save even if it looks like nothing happened.

The Export as Text dialogue.

I've been asked for GIF and BMP support, makes sense as they are indexed modes with no ambiguity. Again something to think about in the future.

The Multipaint BIN project format obviously preserves the palette and the color index, and sticking to the default palette can also be helpful.

The ZX Next specific formats supported:

NXI

NXI is raw bitmap data, without any palette information.

The 256x192 and 320x256 variants can be detected from the file length.

Without palette, they are 49152 and 81920 respectively. With palette, add 512 bytes to length.

Note that the display order is different for the 320x256 version, the image is stored "vertically" in memory.

Multipaint doesn't currently change the screenmode automatically for an in-coming NXI, so you have to first pick the correct mode and then load the NXI. The dialog will warn of incorrect NXI length, though.

Notably, the PLOTIT-LITE paint program included in the ZX Next bundle can load and save 256x192 NXI files.

 

NXI with palette added

The same as NXI, but with 512 bytes of 9-bit palette data. Multipaint can detect which one it is from the file length.

For saving, you have to choose either NXI or "NXI wo" (without).

This format is largely useful for storing, I don't know of any other context of use. 

SL2

256 x 192 raw bitmap data, without palette. These files have a 128-byte PLUS3DOS header to facilitate system loading, or something.

Although the header ends with a checksum, the checksum apparently only matters for the 128 first bytes, thus the value is always the same for this image format.

The importance of SL2 is that the NextBASIC can easily load these files:

10 LAYER 2,1
20 LOAD "picture.sl2" LAYER
30 PAUSE 0

If the picture is in the same folder, NextBASIC should load and display the image.


SPR

SPR is 16384 bytes, raw bitmap data, containing 64 sprite definitions. The sprites are ordered as 16x16 entities, following each other.

Multipaint has no different mode for sprites, the SAVE SPR simply stores the top third of a 256x192 mode screen. This also means whatever is in the remainder, is NOT saved!

Hopefully I can come up with a clearer solution, as the bottom part works nicely as a scratchpad, and there's a chance of losing work.

Some tile work

Preferably, sprites and tiles should be saved in some other format, and only exported via SAVE SPR when needed.

The Sprite/Tile editor included with ZX Next bundle can load SPR files. *.SPR can even be launched from the Browser for inspection.

There's a couple of NextBASIC demos that show how to load and use SPR files in your own Basic programs, I won't go there now.

PAL

PAL is a 512 bytes file which contains the 9-bit RGB definitions for 256-color palette, from index 0 to 255. Practically every odd byte just contains the last needed bit for Blue component of each color.

This is identical to the way the palette is stored in NXI paletted format. It is also a handy order for dumping palette data via color registers in machine code.

This format also facilitates the loading and saving of alternative palettes, in case you need something else than the default palette. I'd recommend sticking to the default palette as much as possible.


NEX

Nex is not an image format, but a more generic means of "packaging" a code, its data and assets into a direct one-file executable, as described here.

I used this opportunity to have a NEX-based self-viewer that can be run from the Browser.

If you use the excellent NextSync for wireless file transfer, you could just export the NEX into your PC sync folder, sync the Next and then run the executable. Not too slow!


A few non-Next related notes

Multipaint is still being developed, and I am headed for a 2024 version, with some overhauls and a possible move to Processing 4.

Tutorial is a funny addition. It can be selected from the start menu. Hopefully, by going through the tutorial, it's more clear what kind of tools and options are available. The tutorial hasn't really been tested much, and may be adjusted in the future.

Another recent addition is a "key cheatsheet" menu item, which shows some (not all) keyboard shortcuts that might come in handy for more effective work.

Generally, Pull Down menus and the icon set and tooltips should give an idea of what is there, but there are also couple of functions that have never been really visible.

For example, scrolling of dither patterns using [ and ] keys is not widely known!

Multipaint website and Downloads

2 comments:

  1. I love the new character count feature for C64 multicolor mode, but would it be possible to add a dedicated character sheet mode? I mean, not a full blown character set editor, but a mode, where I select two screen colors out of 16 and the cell color from the lower eight?
    I wouldn't mind a char editor, but I understand, that this is much more additional work with deep structural changes in the app - but at least honoring the color limitations in bitmap editing would help a lot! Bonus karma points, if you can select the lower eight colors as well as highres colors, where one cell is highres with foreground and background color only...

    ReplyDelete
    Replies
    1. Hi, as you probably guessed the character count was made as the simplest possible way I could include it in the existing mode. Hires/multicolor could not sadly be combined as easily, and as the mode is still multicolor bitmap, it cannot really enforce the char mode limitations.

      Having any char logic is already a little against the Multipaint general idea, and I have to consider if I expand it in the future.

      Delete