Multipaint 2023

With no Multipaint "yearly" release for 2021 and 2022, I thought it was high time to get a version out.

The hiatus was at least partly because of Covid. But maybe not in the way one would expect. You see, for some reason 2020-2021 was at first a time for ambitious new ideas and concentrating on hobbies. This led me to create a huge internal overhaul for Multipaint that eventually became something of a burden, locking me out of a release for a long while.

Often it was like "It would be nice to get that pan tool feature out, but the script features are far from being finished!"

GUI and functions

Indeed from the user point of view one of the biggest additions is the pan tool. In magnify, you can either use the "hand" icon, or hold down the middle mouse button to drag the view.

In the full screen view the pan tool doesn't do anything, which is not that intuitive. Programs like GIMP allow you to drag the full image around, which is kind of useful when preparing to zoom in.

The Multipaint viewport may need rethinking in the future, but I would also like to preserve the 8-bit/16-bit style "full screen" drawing.

The text in menus and buttons now also uses both upper and lower case, which I hope is slightly more readable than the past UPPER-CASE menus. The characters were tweaked a little too, but as it's a monospace, there are always some compromises.

Multipaint 2020 scaled the contents of the window depending on how the full screen fit into the application window. Resizing the window switches between 1-3x scales. Now it's also possible to force one of the scales from the Other menu.

This can be helpful for some situations where you need to fit Multipaint to a low resolution laptop screen. The viewport may overlap the tool palettes, which I didn't fix for now. Using the forced scales, the user is responsible for setting the window size anyway.

The file selector caused some problems for Windows users, which I already knew from Marq's PETSCII editor. Instead of revamping the themed file selector code I disabled it for Windows altogether, which according to one test helped enough. From prefs.txt it is possible to force it back on, in case someone wants to test if the slightly better file selector works.

I adjusted the grid terminology a little. I had happily used "8x8" grid for what was technically a "4x8" grid in wide pixel modes, now it ought to be more consistent.

New Modes

A kind of Amiga mode has been "unofficially" part of Multipaint for a while. However, Multipaint 2023 finally has a resizable, bitplane-adjustable mode that I could properly call Amiga.

Currently it only exports IFF, and cannot load it in, as I found it to be somewhat complex. What kind of IFF would I support? Possibly a Deluxe Paint 3 output would be enough.

Obviously it can handle the Multipaint "*.bin" project format and png load/save, so it's not something to worry too much.

The resize-function is still rather limited, and there's an invisible memory limit to which the mode has to fit into. I consider this an Amiga "low resolution" mode although you can use 1 bitplane and create a 640x400 bitmap.

I guess this would also work as an Atari STE mode, although I haven't written a Degas exporter specific for this mode.

Why even do an Amiga or Atari ST? I no longer remember. Multipaint originally concentrated on 8-bit modes, and it might have been good to hold onto this constraint. For a while, Sinclair QL was my favorite retro machine, resulting in a new mode. Then Atari ST was done as it could be done just as well, and then I began to think what an Amiga mode needed.

VIC-20 hires and multicolor modes were a late addition. I have wanted VIC-20 modes for a long time, but was always somewhat confused with the different implementations, some of which required extra memory and even extra hardware. Aleksi Eeben (thank you!) supplied practically a white paper with specs and examples and a format that could make most out of the unexpanded VIC. I could not resist adding the modes.

Extras Menu

I added an Extras dialogue in the File menu for running less complete, experimental or non-standard modes. I couldn't live with the idea the main platform selector was cluttered with these, but I still wanted more easy access to them for the user. In the future I may revamp the platform selector and again combine the menus somehow.

One of these is the ULAplus direct mode, which is like ZX ULAplus, but the mode doesn't attempt the notorious "live" palette adjustments of the original mode. So it's bit like working on a normal ZX Spectrum with 64 color adjustable palette.

If you turn over to the real ULAplus mode, Multipaint will then convert the image to the real platform limits. Although I've allowed 64 colors, I'd recommend using maximum of about 16, especially because there seems to be something a little wonky about the internal conversion still.

I added a C64 multicolor free mode, similar to the C64 hires free mode. This is meant for experimentation with non-standard C64 ideas, such as mock-up sprites or border effects, or create larger than screen-size bitmaps. Or make pretend you are in a FLI or some such mode.

I also enabled the resize-function for these two modes. Admittedly Multipaint is currently not very good at handling larger screens. I have some ideas about how to expand the usefulness of these modes.

I was asked to add an Amstrad GX4000/plus mode, and it turned out so easy to create I put it to the Extras. This computer enjoyed some popularity in France, but it is not well known for the rest of the world. I do remember it was advertised in Finland. The mode is 160x200 with 16 colors out of 4096 maximum.

Scripting

The biggest change to Multipaint is not really visible to the user at all, the external script functionality.

All the export/import functions were previously written inside the Multipaint source code. Although I could reuse components, this approach began to look like a growing problem if I were to add more modes. Likewise, the component-approach meant that if something broke it could affect multiple other modes. The text exporter was also getting to be a little messy.

Now, Multipaint loads a boot.txt script that defines what other scripts are attached to the current platform File menu and what role they are to play. These scripts in turn use a primitive BASIC-like language to convert the Multipaint internal format into an 8-bit format or executable.

Of course the interpreter takes room in the Multipaint source, but adding new import/export scripts doesn't clutter the source and each platform has a self-contained script. Well, the Amstrad CPC disk baker uses two layers of scripts which I don't like, but it was necessary.

I also encountered the fact that a lazy implementation of a script interpreter isn't especially fast in Java/Processing as the string appending, clipping and concatenation can be costly there. Making it faster took some while, and I can only hope the export/imports are rapid enough.

I'm not yet prepared to say it's a good idea to create your own scripts, but it is possible, they are located in the data folder just as the prefs.txt is.

Into the future

There's actually a bunch of to-do ideas hanging around for a long while, yet I didn't get them into this release version. Now that the scripting idea works I could consider some more lightweight additions.

One future idea is to enable user-creation of modes that are similar to the already existing ones. For example, Amstrad GX4000 was basically a combination of already existing modes and palette selector definition. Almost anyone could have added the mode, except the Multipaint source is so convoluted only I know my way around it.

However, the VIC-20 modes, despite seemingly based on similar concepts as other modes, still required quite a lot of tweaking. So, who knows.

I probably need to look into Processing 4, just to keep up with the official developments.

Multipaint web site:

http://multipaint.kameli.net