Multipaint 2020

I've tried to have a major Multipaint version out each year, at least as long as it makes some kind of sense. Now Multipaint 2020 is out, somewhat later than I hoped. 

The fix-list of every tiny thing is too numerous to put anywhere, the website details the more important ones (http://multipaint.kameli.net). I'll just open up a few points too large to fit there.

The largest step was to move over to Processing 3. This itself doesn't really change the program appearance in almost any way. Hopefully as a newer version it would be more stable and the prefs.txt problems becomes a thing in the past. 

Sadly the transition to P3 means the application is likely slower, something that shows itself on less powerful computers. I compared the Processing 2-based version on Raspberry Pi 3, and found that version to be useable, whereas the new executable made with Processing 3 is quite slow.

This could be due to the way the screen renderer works, but I didn't dare to meddle too much with a thing that worked well in the past.

Application window resizing

(Edit: The feature doesn't work in all Linux desktops. Hang on.)

Edit 2: It does work, too! (24.11.2020)

A major visible change is that I made the application window resizable. Although the program had been already written with a flexible interface in mind, and it could be set from the prefs, the app could not be resized while running. 

However, despite the old code there was still bring a bunch of boring upheavals to the interface drawing and scaling routines.

Dark theme, resized window, SET GRID and a 100% C64->ULAplus conversion caught at the same time.

There are various reasons for making this. One is that there may be low-resolution screens which didn't just about fit the display, so you have a chance to adjust the situation a bit. It's also easier to make larger if it's too tiny for your display, without fiddling with the ZOOM parameter in prefs. Also, if your screen size allows it, it may be nicer to have some more of that good old border visible.

Just to be clear the target platform resolutions are not alterable. I did some behind-the-scenes work to enable non-standard screen sizes, important for Amiga, but this will be a future feature.

I long wondered why Processing 3 does not allow the direct use of size() no longer, or the use of variables as parameters to it. Well, in P3 it's now simply surface.setSize() and works just as well or even better so no worries really.

If the chosen viewport doesn't fit the current scale, Multipaint will re-scale the interface. Also, if you make the application window substantially larger, the scale will follow. Scaling was a feature that was previously only accessible from the prefs.txt ZOOM variable.

The least I now want is to make Multipaint more complex. So, it should still work as before and you might not even notice the resizable window feature if you don't need it.

Resizable window is also a base for future developments, as more flexible target platform resolutions could be made to fit better in the application window.

A very large window will unfortunately slow down a computer, or make your computer choke and start the fans, even if you do nothing with Multipaint. This is something that relates to the way Processing updates the window and apparently can't be helped much.

So, it's somewhat ironic that if you have a huge 4K/8K resolution display specifically for graphic work, then Multipaint might not work ideally on it. Resolutions like 1920 x 1080/1200 should not be too huge. I'd recommend not working on lower display resolutions than 1024 x 768, but it shouldn't be impossible.

Still, the window resizing is less than complete. You can't yet change the actual viewport position, for example.

Dark theme and Set Grid

I added an option to switch between light and dark theme. This did not require much work, as the interface fonts and icons are based on custom routines anyway and not on real fonts or image files.

Set Grid dialogue is something I wanted to add. The already existing grid commands and presets should work as before. This is again a "funny" thing in that the facility for making arbitrary grids has been there for a while, but there was no dialogue to make it happen.

I can only note that when working with 8x8 attribute modes, if the grid does not align with the attribute grid it can be really confusing.

What with the new drawing routines and all, the grid color is again a bit silly. It's like a recurring nightmare. I added a brightness setting as a hasty fix, but as some have commented the grid might have been too dark in their monitors anyway so it is good to have it adjustable. But this is a topic I'll have to look at in the future, again.

Border analysis

When loading png/jpg images, Multipaint will make an attempt to deduce if the image has a border and takes the "real" image from the middle, if it has the correct resolution (or a duplicate/triplicate of the resolution).

For ZX Spectrum and C64 modes this might be helpful when using Multipaint with plain jpg/png files.  It also makes it a bit easier to load existing images from the internet.

I'd still recommend using the BIN file format for project work.

Multipaint loading a 3x PNG file saved from Fuse. (In this case, use SCR, really)

However, if Multipaint can't explicitly determine a border, it will simply load and scale the image, borders and all. For example you might have a small logo in the centre of the screen and a black background and border. In the future there might be a "crop anyway" dialogue.

One problem was whether to include this feature in modes that don't really have a border. But I felt that there might still be quite a lot of images with a "border" in them, such as Atari ST screenshots. So I enabled this for every mode.

Amstrad CPC Overscan 384 x 270 x 16

The original Multipaint interface was very fixed to the idea of having a 320 x 200 resolution at tops. This was also reflected in many, but fortunately not all, internal structural choices of the program.

But now it might be the time to expand these horizons a bit.

To cut a long explanation shorter, instead of resizing buffers I'm using the same room more efficiently to manage the 384 x 272 x 16 resolution.

Just as with all the Amstrad modes, the export template is taken from Marq's Pixel Polizei (thanks!), so you should be able to get the exported images up and running on a real Amstrad. I also followed the export code quite strictly.

The CPC overscan, I'm told, is not really a very standard graphics mode, so I'm now sort of opened the gate for software-enhanced modes(!)

Amstrad CPC mode 1 320 x 200 x 4

This was already in the later 2019 version I think. The mode was a fairly simple addition, but I don't expect many to use it. It is somewhat nostalgic to me as I used to see screenshots of Amstrad games in magazines and they often looked like Spectrum games except with one or two more colors and I wondered how this could be. 

There is an overscan variant but I have not implemented it yet.

C64 unlimited 320 x 200 mode, and other C64 goodies

I added the C64 hires unlimited mode that was previously experimental. It behaves like a C64 320 x 200 mode, with the fixed palette of 16 colors. Howver you can draw the colors freely without any color clash.

So you could basically draw a C64 hires image without Multipaint imposing anything on you, and then move over to the C64 hires mode, and have Multipaint "validate" your image.

The reason for this mode in the first place was I wanted to work on composite sprites, i.e. overlaying different-colored sprites to make hires sprites with many colors. (Or superimpose hires on multicolor sprites). However, it is your responsibility to convert the output png into valid sprite data.

Adding this mode is a bigger change in the Multipaint "philosophy" than might seem and I've felt a bit troubled about it every now and then. However, perhaps better simply make it available and face the outcome.

Why don't all the modes have this option? I haven't still quite decided if this should be a unique mode or rather a switch inside the modes proper.

The transition between different C64 modes is now smoother in that your chosen palette will be preserved and so is the border color. The image is still transferred via "bitmap conversion", but I have not seen any problems coming out of this.

Multipaint at kameli.net