The 10th Anniversary of the first public release of Multipaint (24.2.2016) slid past without me noticing.
I actually started Multipaint in late 2013. It was called "kuppapaint" internally! The impetus at that time had to do with Marq's PETSCII editor, which showed practically how things like file selectors and preferences could be handled in Processing. I also contributed to the PETSCII editor and the rapid development was inspiring.
PETSCII editor fit a very clear gap, but there were already cross-platform pixel paint programs that worked with C64 and ZX Spectrum screenmodes. So even if I had started on a pixeling program, I wasn't initially convinced it would need to be released.
I did notice the existing software mostly worked with Windows only and their development had in some cases ceased.
Grafx2 appeared closest to a multi-platform program that could handle various legacy modes. Yet, to me making pictures with attribute limitations was difficult, and the program itself looked complex with many features I really didn't need. Despite being a Deluxe Paint-inspired software, it actually didn't remind me of Deluxe Paint all that much.
 |
| ZXPAINT Processing sketch, 2009 |
Prehistory: ZXPAINT
I did something drawing-related already on a ZX Spectrum, during 1988 or thereabouts. It was a BASIC program that involved moving a pixel around with a joystick. The line would go on and off with the fire button. A checkerboard dither was available.
On Amiga and Atari ST, I dabbled with BASICs such as ST BASIC, STOS and AMOS, toying around with creating editors and beginnings of tiny paint programs. But under the colossal shadow of Daniel Silva's Deluxe Paint, this never felt really necessary.
Only during the PC era, around the year 2000, I began to see the necessity of making my own editors again. Deluxe Paint was a thing in the past and the new PC programs were cumbersome and seemed to focus on the wrong things. My efforts were mostly sprite- and tile-oriented, written in c and worked directly with key shortcuts and supported my modest game programming ambitions.
 |
| With Allegro or SDL? Not sure anymore |
The "dream" over the years was really concerned with either a full Deluxe Paint style program, or a program that could work with ZX Spectrum attribute limits on the fly. I seem to have been working on at least one version in 2009, called ZXPAINT.
The source code suggests that Processing changed the way file selectors worked, as the source no longer ran without modifications. It might have disappointed me and discouraged me from continuing with this effort.
It didn't look like any of the parts of the 2009 ZXPAINT source were reused in Multipaint, it's more like the experience helped in making slightly better choices later.
 |
| ZXPAINT outcome stupidvampire, November 2009 |
There was also the minor episode of making a doctoral thesis on the topic of self-constructed creative design tools, but I'll leave it at that. It's more that after finished with it, I could again concentrate on hobbies and fun things without the heaviness of heart that comes with having an unfinished thesis looming somewhere in the future.
Multipaint early days
After the premise of the ZX mode had been built into what was to become Multipaint, quite soon I began adding a Commodore 64 Hires mode. I saw myself making C64 hires graphics rather than ZX Spectrum. This was probably because of the 2013 PETSCII wave, I had seen how vivid the C64 scene was and wanted to contribute graphics. Back then it was not even obvious where I could submit Speccy graphics.
I also had a nefarious plan of using my own tool to gain some advantage over competition, but I soon saw it didn't help me that much, and that it would be better to release the tool into the wild. Two images, Inside Job and Countryside, were released before Multipaint itself was out.
An MSX mode was added too, so all the three first modes were attribute-limited in a nearly similar way. After that arrived the multicolour C64 mode, which was already tricky as the program had been hardcoded to support those Spectrum-style graphics. At that point I was supporting all the three major 8-bit platforms I had access to back in the 1980s.
 |
| Some of the first tests of the MSX mode, pre-2016 |
Around this time the idea of a "fantasy console for multi-platform graphics" came to being, meaning that Multipaint pretended to be a computer whose architecture was good for simulating various 8-bit modes. This was too much of a high concept, and I had already been coding myself into the corner, but this idea stimulated my imagination and I kept adding more modes.
It looks like I can't find any pre-2016 Processing sketches, which is a pity. The development diary exists though, and late 2013 entries suggest I worked quite intensely on it from September to the end of the November of that year. After that the ZX and C64 modes and their exports were in place. When I returned in the beginning of 2014, I begun working on the C64 multicolour mode.
Surprisingly, the beginnings of an "Amiga" mode were already in process during 2015. Atari ST was first in a release, though, and the Amiga mode had to wait.
Milestones
Not to make this overlong, there have been some larger milestones in Multipaint:
During the first years, there was a lot of wrestling about how "intelligent" the colour limit adaptation should be. As the program advanced, I dropped off the attempt at providing any kind of heuristics for the colour adaptation, and the program simply changes the underlying colour. After that nobody really complained much about the colour model.
Adding drop-down menus, Deluxe Paint style, made the program far more accessible. I wasn't especially excited about this first, and no-one had really requested it. But many user requests and new features would have been difficult to add if there were no dialogues or menus.
With the menus, it was now possible to "see" what features the program has by glancing at them. I could also now add incomplete and experimental modes to an "Extras" window, and get rid of the separate system dialog for choosing the platform.
 |
| Pull-down menu in Multipaint 2025 |
The first 16-bit modes provided further challenges, but after adding Atari ST and Amiga, and a possibility of switching between modes without restarting the app, Multipaint really became more "multi". Before that, it wasn't even possible to load a file of another platform without restarting Multipaint first.
The recent years have brought app window resize, separate preview window and external scripts for handling the various target platform formats.
One of the newest additions has been the "recentfiles.txt" list, which lets the user load a previously saved file from a short list. This was surprisingly tricky to do, what with the different save formats and scripted save modes. It has likely resulted in some obscure file-related bugs that I may still be hunting for the better part of the next decade.
So, you thought about making a retro paint program?
There's been contenders over the years, but now there's almost a deluge of new paint programs supporting C64 and ZX Spectrum modes.
It's probably not too hard to make a single-platform paint program that's better than one of Multipaint's modes. I still believe there's something valuable in Multipaint's simplicity, and the idea that if you've learned one mode you might want to explore others too. A lot of great graphics have been made with potato-level editors, because the basic drawing functions were good enough.
I'll share some advice, some obvious, some sarcastic, but here goes:
- It's a good idea to show the attribute/colour effects already as the cursor floats over the canvas.
- It's NOT necessary to show a "transparent version" of those effects.
- It's ABSOLUTELY NOT necessary to have a "flashing cursor". Granted, I've not seen this in the pixel programs, but in some PETSCII editors it's a pest.
- Can we have a grid that's not garish and overblown? If the grid is something else than white/grey/black, it will affect the colour perception of what's under.
- Personally I don't understand the need for a pixel-level grid, but C64 programs used to have things like that in the magnify mode. If you do, make an on/off switch.
- Supporting every possible C64-palette known to man? I tried through my own actions to limit the number of palettes in the wild, but to no avail.
- Obviously everyone has to come up with their own keyboard shortcuts, or assume that Adobe products' keyboard shortcuts are a widely accepted standard.
- If I could go back in time, I'd make all possible key shortcuts align better with Deluxe Paint.
- I've tried, when really necessary, look into how GIMP and Krita do things.
- Be assured that if a tool is not very visible in your interface, people will assume it does not exist.
 |
| Extras in Multipaint 2026 |
- In Multipaint, I decided not to go forward with multipage, full animation or layers. I came to realize Multipaint "pretends to be an old paint program" which helped keep it limited.
- Importing could be better, but giving it a thought I don't see it a huge priority. If I can discourage people from making conversion-based images, the better.
- Feature Creep is a thing. Adding a feature seems innocent enough, just make it so it can be turned on/off, man! But even this would add yet another dialog or option in a program that was meant to be simple.
- Some have requested adding really obscure platforms, in the hope their platform would get more support and visibility. But from what I've seen so far, the support doesn't really arrive that way.
- "It doesn't have feature X, therefore crap blah blah" is often talk from people who look at it from the outside, probably without really trying the software.
Multipaint's future is still assured, but not endlessly bright. It depends much on what happens on the Processing/Java front.
