Another year, another version. Making the cut between the "annual" Multipaint version is a little arbitrary, but I think this year there's some cause for this.
For once, the new Multipaint should be a little faster than the old one. This is largely due to using a more Processing-friendly way of rendering the target platform screen as an 1:1 bitmap first and then scaling that using Processing's own image() capability. (Processing is the Java-based environment in which Multipaint is programmed in).
Pan and preview window
For panning the screen around, no new redrawing is needed on the target platform level, making the pan and internal pseudo-window handling (palette, settings) easier.
Previously I felt the non-magnified viewport should be fixed, connecting Multipaint with old programs such as Deluxe Paint, Degas Elite or Art Studio. But it did cause some clunkiness when zooming in and out near the screen edges with mousewheel.
Now I think it's possible to have my cake and eat it too. So, even if the 0-level screen can be panned by middle button drag, if you use the old fashioned magnify tools you might not even see it happen.
The overhaul also streamlined the viewport drawing routines and refreshing the screen. This may open up some new possibilities for handling the screen in the future. The border is no longer "infinite" and there's empty UI area outside the border.
 |
| Huge preview window, and free panning demonstrated |
Having mentioned the pseudo-windows, the Preview window is now a properly detached, separate window, which displays the target screen contents in either 1x or 2x pixels, and in a more correct aspect ratio. This was a solution that has worked well without problems in Marq's PETSCII editor, so I finally dared to use a similar approach here.
There's very little to prevent me from enabling the more accurate aspect ratios in the main screen, but I still have a hunch it's better to keep pixels in integer proportions, as scaling can produce ugly artefacts.
Processing 3 and Processing 4
Another issue concerned moving over to the newer Processing 4. This shouldn't be a huge deal, as the same source now appears to work in both without changes.
Some reports have been trickling in of Multipaint again not working in some Windows or Mac configurations, whereas it appears a Processing 4-built application might work in these situations.
However, the Processing 4 -build requires OpenJDK 17 or higher. At least the creators of Processing have now made this very clear. In the past I felt it was slightly uncertain if OpenJDK is even fine and if so, which version to use. Or I simply couldn't be bothered to find that info.
Because it might be a chore to get OpenJDK 17 working, and your old Multipaint works fine, I still offer the main download as a zip with Processing *3* builds. The Processing *4* builds are in a separate zip available on the website, in case you feel the old Java/Processing is the problem.
Edit: In Linux Mint you can simply open the Software Manager, search for "openjdk" and choose to install for example Openjdk-21-jre. After this, the P4 version of Multipaint should work.
Sadly, as progress moves on, older computers might no longer have meaningful way to update Java or OpenJDK. Acquiring a cheap/free recent enough Linux laptop shouldn't be too hard, though?
Processing might eventually have an end-of-life too, but at least they still bother to chase the recent developments.
Big screens, small screens
With the improvements above, I was quite happy to use even a maximized app window on a 2560x1440 display. But as usual, it may be your xxxtreme graphics workstation with super-high resolution doesn't provide the best environment for Multipaint. I would still suggest not maximizing the window.
At another end, after freeing the panning, coupled with better GUI scaling and the preview window separation means that on a small-resolution screen (~1440x768) you might be able to find more helpful window positions. For example, the Multipaint main window could mostly serve as a magnify window, while looking at the Preview window for overview.
 |
| Main window and preview window side by side |
I did fiddle around a little with Raspberry Pi 400, Multipaint does work on Raspbian OS and it is reasonably possible to draw using it. I wouldn't use a large desktop resolution, as a huge Multipaint window slows things disproportionally. Conversion tasks, both from files and in between modes, are also quite slow.
On Raspbian, the file selector may look horrible, the worse the higher the desktop resolution, and I may eventually adopt Marq's choice from his PETSCII Editor. It is generally better and seems to work on Raspbian.
Unique Character count, "UQ"
Unique Character count was added to the C64 multicolor mode, just to test see how Multipaint could help in creating character graphics. The feature request and testing was done by Shine.
At the infobox, UQ: displays the number of unique characters in use. Multipaint checks whether the screen would work as a multicolor character screen, but doesn't understand the mixing of hires and multicolor modes. If there's a problem the infobox will just bluntly say "UQ:???" and you have to figure it out.
The multicolor character mode has three separate global colors, and each character area can have one more color, just as long as this color is from the range 0-7.
It might make intuitive sense to use global colors from the 8-15 range, as you cannot reach them from the per-char color. However, many images and games still use 0 (black) as global color to have more freedom to combine the 1-7 colors with black.
 |
| This screen uses 75 unique characters, the three greys form the global colors (screen bottom) |
Although the multicolor screen background is always selected manually, UQ estimates what the two extra global colors might legally be (shown below the selected colors, among the global color) and understands the use of 0-7 colors in character-by-character basis.
This is also partly the reason the feature can't (yet) be more specific in showing where the "mistakes" are, as it's a little tricky to make a difference between "you messed a global color" and "one of these characters doesn't work".
The character idea might not fit that well with the Multipaint philosophy of drawing single standard bitmap screens in simple way, but there it is. I felt the routines might serve more generally as a rudimentary packer, or for creating modes that have character limitations built-in. The long-coming Panasonic JR200 mode springs into mind.
UQ may be improved in the future, and exporting as a character mode screen should be a possibility.
Other enhancements
At the tail end of Multipaint 2023, I added the ZX Spectrum Next modes. The bugs and even the occasional crashes this addition created, should be fixed for 2024 version.
I added some Commodore 64 goodies, mostly things that work under the hood. Loading in a PNG file that contains standard C64 graphics in 320x200 resolution should now work better.
Multipaint can have a hunch of what kind of palette has been used, and make a good guess of what the background color should be in multicolor mode. This is simply achieved by converting the same image 16 times(!), to see which of the background colors produces the least "lossy" conversion.
As before, a really non-ambiguous border around the 320x200 area will be cropped, and this has not been improved in any way.
Still, the conversion engine is not that great and I have no big intention to develop Multipaint into a generic conversion tool. But as I said, it should load C64 images more accurately from PNGs.
This also affects the internal conversions, switching from other modes towards C64 may produce better color identification and a more useful background color in multicolor. This is especially important if using the C64 multicolor "free" mode to create something that works in another background than black.
Opportunities for some tiny UI fixes always arise. Just a couple of examples: If the magnifying glass tool is currently on, the mousewheel zoom would behave erratically, now it's cleaner. You can pipette the border area and get its color that way.The Future
It's already more than ten years since I started Multipaint, although the first public release was at 2016!
This version shortened my to-do list somewhat, but there are also long-standing issues and omissions I could not yet cram into this release. Usually the major Multipaint release gets advertised a little more and I will find out the changes broke something or didn't quite work as intended, and this will take some of my time.
Despite the messy and sprawling nature of the code, I still have a pretty good grasp of how it works and how to do changes to it. I have a good idea of what can be fixed quickly and what needs a more dedicated effort, and what probably isn't worth trying to change anymore.
I had mused about the viewport overhaul in my mind for a long time, and then it was surprisingly quick to do. Trimming it around the edges (almost literally) took more effort.
At CSDb
No comments:
Post a Comment