wjaguar
commented
1 year ago Sorry for answering this late. The thing with non-square pixels is, all the brushes will either be deformed into a less-than-useful state if left as they are, or need a sizable changeset to reimplement them for this eventuality. Because at present, the "brush square" in mtPaint does not have separate width and height dimensions, but instead, one single "size" value. And as the circular brushes will have to become ellipses to stay visually circular, the calculation of their traces will need be redone in a more generic manner than now, too. I.e. while doubling pixels width on display is not that hard, that would also result in double-width brushes, and combating that is nontrivial work for, frankly, a very corner case that mtPaint was never intended for.
Myself, when I was handling 160x200 and similar images (the example files, when writing and testing the LBM loader), I simply bound a short pixel-doubling script to a hotkey: "-i/scale .=near asp=0 w=x2", to make 160x200 into a square-pixeled 320x200, etc. in a single keypress. The keyboard mapper sees scripts as "_Image/Scripts/1..10", with the numbers corresponding to the rows in the Image->Scripts->Configure dialog. If I had to paint such an image, I would have done so in 320x200, doubling the pixels by hand, and when I need the line tool, I could halve the width back with a similar hotkey-bound script: "-i/scale .=near asp=0 w=x0.5", draw the line, and double it again afterwards.
This could be implemented as different X & Y zoom ratios or a stretching factor in X for the displayed image.
Context: I'd like to make some sprites for the Amstrad CPC which uses some weird resolutions (160x200 when using 16 colors) resulting in non-square pixels.