Bounty proposal: Paint

There was one oddity with the Zoom with Ctrl+resize window that is worth mentioning while I think of it.

In Paint when the sprite is very small e.g. 32 × 32, or very far zoomed out, its on-screen size is smaller than the minimum permissible sprite window size (minimum window width is dictated by the sprite name). This results in a visible margin around the sprite in the background colour, usually black.

When you drag a sprite window to the minimum size as above and then zoom in using the menu, first the sprite expands to fill the black background without enlarging the window. What this means of course is there are many different zoom levels that can show the same area of sprite for that one minimum window size.

This leaves us with two straightforward options when attempting to Ctrl+resize to zoom in such a small sprite with a visible margin:

1. As the window is enlarged, the black margin enlarges with it, so the sprite always occupies the same fraction of the window as it did before the operation.
2. As soon as the Ctrl + resize is started, the sprite immediately zooms in to fill as much of the window as possible. Expanding the window further expands the sprite proportionally. Shrinking the window back to the minimum size, leaves the sprite filling as much of the window as possible.

Personally, I prefer option 2, on the grounds that the black margin is effectively wasted space. I see little use in enlarging that wasted space and that certainly doesn’t happen when you zoom using the menu UI. If the user really wants to zoom the sprite further out once the window is at its minimum size, they can just use the menu dialogue or keyboard shortcuts.

If anyone strongly disagrees with this, I’d be interested to hear your thoughts. I briefly considered other options like an accelerated zoom of the sprite when the window is close to its minimum size but dismissed it as much too counter-intuitive and not really useful. I could also make the above two options configurable but I don’t think there’s much point.

I don’t know if it’s feasible, but something like Ctrl+0 (zero) – like many browsers use – to reset the zoom to 100% regardless of the window size might be useful, so that you can get back to the ‘right’ size for the sprite quickly and easily.

I don’t know if it’s feasible, but something like Ctrl+0 (zero) – like many browsers use – to reset the zoom to 100% regardless of the window size might be useful, so that you can get back to the ‘right’ size for the sprite quickly and easily.

Good idea. I was thinking Ctrl + number could be keyboard shortcuts to select Paint tools but then there’s already 21 of them so maybe not. We could have Next Tool / Previous tool shortcuts but then there’d probably need to be better visual feedback than relying on the tools window. Feature creep! :-(

In !Draw, ^R swaps between the last two zoom levels, ^Q and ^W zoom in and out.

In !Draw, ^R swaps between the last two zoom levels, ^Q and ^W zoom in and out.

Wonderfully "I’ve got no up/down arow keys on this legacy keyboard innit?
^up arrow, ^down arrow anyone?

+1 vote for Option 2. That behaviour matches the menu UI, as you say.

- Option to add a full palette to 256 colour sprites

From Sprite editor window: Edit > Palette.

It gets a tick when there is a palette.

Hmm, I’m sure that when I last tried that it only added a 64 entry palette, not a 256 entry one (and that Paint refused to allow you to edit 64 entry palettes).

I’ve just changed the code so choosing “Colour palette” for a new 256 colour sprite adds a 256 entry (colourful) palette rather than the 64 entry one and can confirm that Paint allows you to edit the colours (only tested on RPCEmu with RISC OS 5 so far).

This brings to mind two questions though. Firstly, and most importantly, will this new behaviour cause headaches for any users? Is there anyone that needs to retain a feature to create 64 entry palettes from Paint?

The second question is why oh why did Paint have this strange logic to begin with? It was deliberate checks in the code to choose 256 entries for “Mono” and 64 for “Colour”. Is it something to do with the way the GCOL commands split into 64 colours and 4 tints? Are there old machines or platforms (Arthur? The Beeb?) that will only support 64 entry palettes?

If someone can convince me it’s still needed, we’ll have to find a way to stick the option in the UI that isn’t too ugly. The radio buttons on New Sprite could be changed to “256 colour palette”, “64 colour palette”, “256 grey palette” for 256 colour sprites but I think that’s pretty awful and space is at a premium! I suppose an environment variable is a last resort.

Actually they’re going to have a hard job convincing me it’s still needed given that editing the 64 entry palettes seemed to be utterly broken in Paint, which means anyone that created them must have found another application to edit them, or done it via code, in which case, why use Paint to make the palette at all? ;-)

It’s the behaviour of VIDC1 machines (pre RiscPC); the 256 colour sprites were introduced with RISC OS 3. Might be good for backward compatibility?

RO4 Paint is also odd – colour means 64, mono means 256, but if you remove the palette using the menu, you can only thereafter add a 64 entry palette. Don’t forget that 16 entry palettes are also legal for 256 colour sprites.

256 colour sprite palette sizes:

• None
• 16 – old ‘colour’ palette
• 64 – *ScreenSave/!Paint palette
• 256 – full palette

the 256 colour sprites were introduced with RISC OS 3

I think you mean 256 entry palettes.

I think the option should be retained for compatibility, even if it’s hard to think of a reason for creating an old-style (64*4) 256-colour sprite with a palette.

In terms of the UI, my own view remains that adding more radio buttons is adding ugliness to an already very ugly window :) I think, given the plethora of sprite colour depths and options, that replacing the radios with drop-down menus is the only way to go. The scheme I’d prefer is to have one drop-down menu with sprite colours as follows:

Colours >
16 million
32 thousand
256 (editable)
256 (fixed)
16
4

The ‘256 fixed’ option would create an old-style 64*4 entry sprite.

There would then be a second drop-down menu for the palette option, with its contents dependent on the colour depth selected. For high-colour sprites, the drop-down box would be greyed-out (no palette options). For 2, 4, 16-colour sprites, the choice would be:

Palette >
None
Greyscale
Colour

For the ‘fixed’ 256-colour sprites, the choice would be:

Palette >
None
Colour

In this case, the ‘Colour’ entry would be really for compatibility.

For 256-colour sprites with editable palettes, the entries could be potentially really useful:

Palette >
None
Greyscale
Acorn [the default set]
Web-safe
Sepia [etc...]

Although that’s a more complex scheme to implement, in UI terms it seems really neat to me: two controls for the whole set of options.

The ‘256 fixed’ option would create an old-style 64*4 entry sprite.

In this case, the ‘Colour’ entry would be really for compatibility.

This is the bit I don’t really get. I never had RISC OS 2 for very long and that was many years ago, so my memory is hazy. Was it ever possible to edit the colours of the 64 entry palettes? Are we calling it “fixed” in the sense that Paint can’t edit the palette?

If the 64 entry palettes weren’t editable, why have them saved with a sprite at all?

I’ll have to see if I can dig out a RISC OS 2 version of Paint to remind myself what it does.

I like the idea of using drop-downs, by the way.

Just fired up ArcEm and Paint version 1.61 under RISC OS 3.11 and, yes, Paint→Edit palette is greyed out for a 256 colour sprite with a palette. I can’t try RISC OS 2’s Paint as I have no clue where my RISC OS 2 application discs would be now if they were even still readable!

https://4corn.co.uk/aview.php?sPath=/archiology/osdiscs/riscos2

I think you mean 256 entry palettes.

Yup. They clearly aren’t that common. I had to fix, sorta recently, Ovation not coping correctly with them. Perhaps !Paint’s inabilities helped make it a rarely used formats.

The scheme I’d prefer is to have one drop-down menu with sprite colours as follows:

Agreed. The current setup is messy and confusing. Adding to that would be bad. There are so many possible options that menus are the only sensible way forward.

I can’t try RISC OS 2’s Paint as I have no clue where my RISC OS 2 application discs would be now if they were even still readable!

Google is your friend: https://www.google.com/search?q=risc+os+2+application+discs

Edit: Jeffrey’s link just above is third down in Google’s results. That site is worth bookmarking as it’s a haven for “obscure weird old stuff”. Want to know what the OS could do with sprites in the mesolithic era? Pop over to the documents and you will find scans of the PRMs for RISC OS 2 and Arthur!!!

Aha! Thank you. I had a poke around 4corn already but missed “archiology”! :-)

Was it ever possible to edit the colours of the 64 entry palettes? Are we calling it “fixed” in the sense that Paint can’t edit the palette?

I don’t think it ever was in Paint (hence the suggestion to refer to it as ‘fixed’).

If the 64 entry palettes weren’t editable, why have them saved with a sprite at all?

I don’t know! However, since it has been possible to do in the past, I think Paint should carry on being able to do so.

I can’t argue with that! ;-D

Colours >
16 million
32 thousand
256 (editable)
256 (fixed)
16
4

That’s a bit strange. Better I think to keep the number of colours being the number of colours, and leaving the choice of palette for the palette menu.

Palette
-------
None
256 colours
256 greys
64 (fixed)
16 (fixed)

Further strangeness – as well as the 16 and 64 entry palettes for 256 colour sprites, one has to consider Paint’s behaviour when saving “the palette” as a type &FED – regardless of the number of colours in the palette, if the palette is saved it is expanded to 256 entries, so the fix was always to save the palette back into the sprite, which forces it to be 256 entries. That always worked, so it was weird there was no specific menu entry to do the same.

And the oddity about Palette files is that if you save the palette of a 16 colour sprite it will have 20 colours in it, as Paint saves the border and mouse colours at the same time. This was to aid compatibility with the ancient Palette program – remember that?! Dragging such a 20 colour palette into a 16 colour sprite ignores the border and mouse colours of course.

Also note that despite the fact that Palette files are simply a VDU stream (like BBC Font) and the 20 colour version proves that the VDU19 parameter is important for distinguishing the border and mouse colours… and despite the fact that sprite palettes are pairs of colour words to allow for flashing colours, Paint has never coped with type 17 and type 18 (flashing) colours in Palettes, and a sprite with a flashing palette only has the first colour saved in the Palette file.

And Paint doesn’t cope with a Palette file with fewer colours in it – eg 1 – which is a great pity as that would allow one to drag colours from palette to palette.

It was all a bit half-arsed really.

That’s a bit strange. Better I think to keep the number of colours being the number of colours, and leaving the choice of palette for the palette menu.

Yes, that would be better. My suggestion wasn’t ideal perhaps from a neatness point of view, but it aimed to capture the sense that, to the user looking to design graphics, there are basically two ‘types’ of 256-colour sprite – the ones with meaningfully editable palettes (including possible new useful presets), and the ones where you’re stuck with the default.

However, your scheme is simpler and more accurate. Under this system, you could still use the palette dropdown to allow selection of alternative preset 256-entry palettes, but you’d possibly have to use a separator to make the two types clear, eg:

Palette >
None
------------
Colour
Greyscale
Web-safe
Sepia
------------
64 (fixed)
16 (fixed)

Andy – your call, I think!

And Paint doesn’t cope with a Palette file with fewer colours in it – It was all a bit half-arsed really.

Yes, though improved palette handling is on the Bounty list, IIRC, so there’s hope!

I tried manually altering a 16-entry palette in a 256-colour sprite. When I loaded it in to !Paint it still showed the default palette. I see the correct colours if I load it in !Draw. Looks like this has been broken since RISC OS 3.5.

As for 64-entry palettes, RISC OS only seems to be using the first 16 colours (contrary to the PRMs which say the last 16 are passed on to the VIDC). The other 48 entries may as well be junk. Aside from wasting memory, what is the point in a 64-entry palette?

I find that if I use !Paint to create a 256-colour sprite with a palette, then it gets a 64-entry palette. If I then tell !Paint to remove the palette and then add it again, it now has a 16-entry palette.

This is great. The only way it could be better is if Paint randomly decided to crash and save all its files in !Scrap with the wrong names oh it does that already.

That’s a bit strange. Better I think to keep the number of colours being the number of colours, and leaving the choice of palette for the palette menu.

You read my mind, nemo. Sorry Chris! The only bit I don’t like is we have “256 colours” but then “64 (fixed)” where it’s not telling us that they’re colours, or what they are (entries really). I can’t think of anything better though without making the text too long for low resolutions, so I’ll probably go with it.

For the time being, I’ll add options for 64 and 16 entry fixed palettes. I have to say I’m mildly curious what would happen on an old machine if I enabled editing of those palettes though!

As for all the other bugs you all just mentioned, the alternative preset palettes and the “improve palette handling”, I’m afraid they’re all going to have to wait until the end of the bounty, if and when I ever get that far!

Yes, though improved palette handling is on the Bounty list, IIRC, so there’s hope!

It is, according to the web page, but ROOL told me it could be dropped to save time if necessary. As above though I might be willing to do it for free after everything else is finished.

Editable vertical/horizontal DPI {45|90|180}

Regarding Martin Bazley and Michael Drake’s comments:

Supplement to earlier request to implement DPI/colour changes: Ability to do that without modifying the sprite data. For use when the sprite is in the wrong format for whatever reason. (This wouldn’t cause memory problems, as sprite width is internally represented as words rather than pixels, so changing the BPP would automatically change the width in pixels.) I know, I know, I’m probably the only one who’d ever use it…

That would be behaviour that would seem completely broken to almost all users.

Changing bpp the way people expect is complex, it’s even usually lossy when reducing bpp, and may be better left to other apps.

On other image editing software on other operating systems, the DPI is normally for print and as such is specified independently from the width and height in pixels.

I’m thinking a dialogue to change the DPI should at least allow the user to see the effect on the width and height in pixels. It should probably show the resultant screen mode as well.

I’m thinking the ideal would look something like this (a Scale image dialogue):

------------------------------
|         Scale              |
|----------------------------|
|X dpi () 45 (o) 90 () 180   |
|Y dpi () 45 (o) 90 () 180   |
|[/] Set pixel size from dpi |
|                            |
|            < >             |
|Width     [ 640 ] pixels    |
|         ^                  |
|Height   V[ 480 ] pixels    |
|                            |
|[/] Lock aspect ratio       |
|                            |
|Mode [28]                   |
------------------------------

“Set pixel size from dpi” would be checked by default and would mean that changing the radio buttons would alter the values entered in Width and Height below. Also, when “Set pixel size from dpi” is checked, “Lock aspect ratio” would be checked and greyed out. The user could still type in their own Width or Height without affecting the dpi selection, but obviously “Lock aspect ratio” will update the other dimension automatically.

Mode would be read-only just like on the New Sprite dialogue.

The interface of my dreams would also include Quality options to choose between “Nearest pixel” and “Bilinear interpolation” which I’d enjoy coding but is arguably beyond the scope of the current bounty (I’ll ask ROOL). That might only be an option for high colour sprites anyway to get a result that looks half decent. I suppose in future, a separate dialogue to change the colour depth could use Floyd-Steinberg dithering or similar to reduce the colour depth afterwards.

I think if we went with the dialogue I’ve mocked up above, we should probably ditch the separate “Scale x” and “Scale y” menu options as well. Also why does Paint have DPI in lower case?

Actually, most people opening “Scale sprite” would probably be more interested in the pixel dimensions than DPI, so those should probably move to the top:

------------------------------
|       Scale sprite         |
|----------------------------|
|            < >             |
|Width     [ 640 ] pixels    |
|         ^                  |
|Height   V[ 480 ] pixels    |
|[/] Lock aspect ratio       |
|                            |
|X dpi () 45 (o) 90 () 180   |
|Y dpi () 45 (o) 90 () 180   |
|[/] Set pixel size from dpi |
|                            |
|Mode [28]            _____  |
|                    [Scale] |
------------------------------

Based on this, greying out “Lock aspect ratio” when “Set pixel size from dpi” is checked is probably a bad idea too. I think it would frustrate users not knowing why it was read-only, when they weren’t interested in the DPI at all. I think it doesn’t need to be read-only, so long as changing the DPI radio buttons always (provided “Set pixel size from dpi” is checked) fills in a new Width and Height recalculated from the actual current image dimensions.

I also take back my comment about ditching the separate “Scale x” and “Scale y” menu options as well, unless we add them to the above dialogue as well (X scale factor, Y scale factor), as they are useful.

I renamed it “Scale sprite” as it’s more descriptive and the text easily fits.*

_{*It was “Scale Image” but they’re only ever called sprites elsewhere in Paint.}