Bounty proposal: Paint

Hmm. Where did that go?

I’ve tried to reconstitute it here. Did I get everything? (I deliberately omitted the PNG feature, not because it’s not very desirable, but just as it seems quite a big addition for a first stage bounty. However, happy to put it back if others disagree.)

Overview

Recent changes to the OS’s sprite handling capabilities make it desirable to update Paint. The following bounty would bring add support to all new sprite formats, as well as adding some features and fixing some longstanding bugs.

Detail of proposed changes

Sprite Formats

Handle sprites with alpha mask
Handle sprites with alpha channel
Handle 64K and 4K colour sprites
Update sprite info, including compatibility data

General Editing

Spritefile windows gain input focus on first click
Key shortcuts in Spritefile windows
Undo/Redo function
Edit alpha mask
Edit dpi setting {45|90|180}
Enhanced Brush tool

Colour handling

More comprehensive palette editing
Artist-friendly 256-colour palette ordering
Create editable 256-colour sprites
Current fore/background colours indicated in editor window
Colour Picker provides Hex colour values

Selection, zoom and resize

Snap view to selection box
Scrollwheel zoom
Auto-zoom when dragging resize with keypress
Add/remove row/column tool added the toolbox
Dialogue box to enter rows/columns on each side Ticket #136
Wrap option for Move Sprite tool

Bug fixes

Crash on brush selection Forum thread
Crash on using slider bars Forum thread Ticket #339

That looks about right to me. And don’t forget the links!

Brush crash: Forum thread
Colour picker crash: Forum thread, Ticket #339
Crop/resize suggestions: Ticket #136

There’s also the toolbar request, although I believe we’re aiming to leave that out of the bounty as it’s a bit controversial: Ticket #138

Added :) I think Michael had some tweaks for the Selection/Zoom stuff, which would be easy to add too.

Re the toolbar, I think best to leave for now and focus on the compatibility work. I’m still quite keen on some kind of optional toolbox enhancement/attachment, but any possible changes would need to be handled very cautiously, with plenty of consultation :)

The artist-friendly rendering of the default 8-bit palette was on there. There was also a section on the brush tool. Also there was one about adding a Wrap option to the Move whole sprite tool.

Do ROOL have a backup it could be recovered from?

Do ROOL have a backup it could be recovered from?

I can’t answer that question right now – it’s one for Andrew and he’s in the process of coming back to the UK from New Zealand over the next few days.. realistically, it’ll probably be faster to recreate this page.

I’ve added Michael’s points. The headline points here are really just placeholders – anyone implementing the features will probably want to trawl this thread anyway to get the detail, or consult as part of the process.

I deliberately omitted the PNG feature, not because it’s not very desirable

I think that’s in keeping with the spirit of the OS: in Unix for example, you can pipe the output of one command into the next program, to serialise processing. In RISC OS you drag and drop between applications in the desktop.

At present non native bitmap import is drag to ChangeFSI, drag resulting sprite into Paint, drag result to a disc drive to save it. ie. Paint only knows how to edit those bitmap formats that the OS also inherently knows how to display (JPEG and sprites). If you pile a load of PNG code into Paint, that only helps Paint, all the other programs you might use (Draw for example) still can’t open them.

That leaves two options – implement many foreign file imports centrally in the OS (in essence I think that’s what the ImageFileRender stuff does in RISC OS Select?), or put the foreign file import along with all the other ones in ChangeFSI. Adding PNG to ChangeFSI shouldn’t be a massive brain ache, since we already have a ZLib module which is the compressor used by PNG I think.

This keeps the proposed Paint bounty a bit easier to swallow.

The artist-friendly rendering of the default 8-bit palette was on there

I’m no artist, but I find the existing layout quite easy to understand. There are pools of 4×4 colours, and each pool is the same basic colour but with a different luminance – so if I want a darker version of the same shade of green I just count up (or across) 4 squares. I appreciate not everybody’s mind is wired like mine, thankfully.

I think Michael had some tweaks for the Selection/Zoom stuff, which would be easy to add too.

Yes, I reworked bits and pieces for clarity. I also added a few things and fixed a bit of grammar. I’ll try to redo it here.

Overview

Recent changes to the OS’s sprite handling capabilities make it desirable to update Paint. The following bounty would add support for all new sprite formats, as well as adding some features and fixing some long-standing bugs.

Detail of proposed changes

Sprite Formats

• Handle sprites with alpha mask
• Handle sprites with alpha channel
• Handle 64K and 4K colour sprites
• Update sprite info, including compatibility data
• Editable vertical/horizontal DPI {45|90|180}

General Editing

• Sprite editor windows gain input focus on first click
• Key shortcuts in Sprite editor windows
• Undo/Redo function (F8/F9)
• Edit alpha mask/channel
• Add “Font” and “Size” options to Text tool
• Add “Wrap” option to Move Sprite tool
• Enhanced Brush tool ideas:
  • Add opacity slider
  • Alpha channel sprite support + sprite brushes effectively provide airbrush support
  • Make it more user friendly (the typing in sprite/shape names interface isn’t ideal)
  • RISC OS version compatibility issues (Forum post)

Colour handling

• Improved facilities for editing palettes
• Artist-friendly ordering of the default 256-colour palette (Forum post)
• Able to add fully editable 256-colour palette to sprites
• Current fore/background colour indicators in editor window (Forum posts: 1st 2nd)
• Colour Picker able to show, and allow entry of, hexadecimal values
• Enable use of Adjust to paint with background colour in >256 colour sprites
• Shift+Select click selects as foreground colour (as Paint > Select colour menu option)
• Shift+Adjust click selects as background colour

Selection, zoom and resize

• Autoscroll with selection box drags
• Zoom with Ctrl+Scrollwheel
• Zoom with Ctrl+resize window
• Toolbox button for Add/remove row/column tool(s)
• Dialogue box to enter rows/columns on each side (Ticket #136)

Bug fixes

• Crash on brush selection (Forum thread)
• Crash on using slider bars (Forum thread Bug ticket #339)

Here’s the Textile source for the above:

h3. Overview

Recent changes to the OS’s sprite handling capabilities make it desirable to update Paint. The following bounty would add support for all new sprite formats, as well as adding some features and fixing some long-standing bugs.

h3. Detail of proposed changes

h4. Sprite Formats

* Handle sprites with alpha mask
* Handle sprites with alpha channel
* Handle 64K and 4K colour sprites
* Update sprite info, including compatibility data
* Editable vertical/horizontal DPI {45|90|180}

h4. General Editing

* Sprite editor windows gain input focus on first click
* Key shortcuts in Sprite editor windows
* Undo/Redo function (F8/F9)
* Edit alpha mask/channel
* Add "Font" and "Size" options to Text tool
* Add "Wrap" option to Move Sprite tool
* Enhanced Brush tool ideas:
** Add opacity slider
** Alpha channel sprite support + sprite brushes effectively provide airbrush support
** Make it more user friendly (the typing in sprite/shape names interface isn't ideal)
** RISC OS version compatibility issues ("Forum post":https://www.riscosopen.org/forum/forums/8/topics/2146?page=3#posts-26353)

h4. Colour handling

* Improved facilities for editing palettes
* Artist-friendly ordering of the default 256-colour palette ("Forum post":https://www.riscosopen.org/forum/forums/8/topics/2146?page=3#posts-26316)
* Able to add fully editable 256-colour palette to sprites
* Current fore/background colour indicators in editor window (Forum posts: "1st":https://www.riscosopen.org/forum/forums/8/topics/2146#posts-26275 "2nd":https://www.riscosopen.org/forum/forums/8/topics/2146?page=3#posts-26315)
* Colour Picker able to show, and allow entry of, hexadecimal values
* Enable use of Adjust to paint with background colour in >256 colour sprites
* Shift+Select click selects as foreground colour (as Paint > Select colour menu option)
* Shift+Adjust click selects as background colour

h4. Selection, zoom and resize

* Autoscroll with selection box drags
* Zoom with Ctrl+Scrollwheel
* Zoom with Ctrl+resize window
* Toolbox button for Add/remove row/column tool(s)
* Dialogue box to enter rows/columns on each side ("Ticket #136":https://www.riscosopen.org/tracker/tickets/136)

h4. Bug fixes

* Crash on brush selection ("Forum thread":https://www.riscosopen.org/forum/forums/4/topics/2068)
* Crash on using slider bars ("Forum thread":https://www.riscosopen.org/forum/forums/4/topics/1782 "Bug ticket #339":https://www.riscosopen.org/tracker/tickets/339)

who edits sprites in Paint at 1:1?!

BITD, probably mainly primary school kids creating bitmap art!

…and also Acorn User competition winners in 1991 (pg.64 “Bob Hooper’s winning entry, The Chariot of the Gods, produced using Paint”)!

Re: displaying compatibility data: I started work on this over the weekend, while fixing up a few bugs to do with editing RISC OS 5 format sprites. I’ve reworked the sprite info dialog so that it will show the following (top-to-bottom, if memory serves):

• Sprite name
• Mode – either a mode number or raw hex mode word. Displaying the raw mode word seemed like a good idea at the time, but I’m now not that sure how useful it’ll be to regular users
• Size (bytes)
• Colours – This information is now always displayed, even for numbered modes (assuming the OS can work it out). For true colour sprites it’ll also show the colour space (RGB, CMYK, etc.) and RGB component order (BGR, RGB, ABGR, ARGB)
• DPI
• Mask – “Yes”, “No”, or “Alpha” for a RISC OS Select alpha mask.
• Alpha – For sprites with a RISC OS 5 alpha channel the mask display shows the bit depth of the alpha channel instead (1, 4, 8)
• Palette – “Yes” and “No” being the usual, except for 256 colour sprites which have “Partial” and “Full 256”
• Width & height (pixels)
• OS compatibility. For all the new format sprites it shows both ROL & ROOL version info where suitable, e.g. 64k colour sprites will be listed as both RISC OS 5.21 & 6, while CMYK will only be listed as RISC OS Select since we don’t have full support for them yet.

Anyone have anything else they’d like to see? I’m thinking I might shift the mode display to further down the bottom, as there aren’t likely to be many people who care what the raw mode word looks like, and for numbered modes it’s also a bit redundant now that Paint will (attempt to) display the colour information. And probably move the width & height further to the top since they’re probably more important than all the detailed colour/mask information.

Also if we’re going to display compatibility information, I think it’d also make sense to have functionality to make it easy to convert sprites to/from formats which different OS versions can support. I.e. a dialog you can open up where you select which OS version you want a sprite (or selection of sprites) to be made compatible with, and a few simple options to control conversion (e.g. whether custom or default palettes should be used, cutoff value for converting alpha data to a mask, dithering controls, use of 90×45 DPI modes for Arc sprites, etc.)

Then when you click ‘OK’ it can probably just run ChangeFSI on each sprite in turn in order to do the actual conversion (to keep Paint relatively lightweight and avoid duplicating lots of code from ChangeFSI).

Alternatively we could tackle the problem from the other end and add the same compatibility information display to ChangeFSI – although I’d argue that ChangeFSI isn’t ideal for this kind of thing as it can (AFAIK) only deal with sprite files containing individual sprites, which would make things painful if you’ve got a sprite file full of tool/icon sprites which you want to convert to a different format.

Looks great to me. Some quick thoughts:

- I agree that the raw mode word won’t be very useful to most users, and the standard mode number would be better. I think it would be best to move this down to the bottom, as you suggest, and make the pixel dimensions higher priority.

- Basic conversions would be incredibly helpful. Top of my wishlist would be a way to convert dpi settings (e.g. for designing EX0,EY0 sprites), but that’s beyond the scope of what you’re proposing!

- I’ve always thought that the ‘Display full info’ window layout was a bit wasteful of space. If you’re looking into sprite info settings, could you tweak the info displayed in the spritefile window too? It might be possible to format this a bit more neatly/concisely. Ideally, I think the window should list Colours in all cases, rather than Mode numbers, even with old-style Mode sprites. If users want to check the Mode number (if present), they can use your new extended info dialog.

Very happy to test out any changes or help designing templates, etc.

. Compression method

?

(would be a nice add-on)

Here are two layouts that I’ve come up with for the sprite info display. I think I prefer the tall one over the wide one.

Anyone have any opinions?

- I’ve always thought that the ‘Display full info’ window layout was a bit wasteful of space. If you’re looking into sprite info settings, could you tweak the info displayed in the spritefile window too? It might be possible to format this a bit more neatly/concisely. Ideally, I think the window should list Colours in all cases, rather than Mode numbers, even with old-style Mode sprites. If users want to check the Mode number (if present), they can use your new extended info dialog.

Yes, it does look a bit wasteful. However I think a lot of the space is necessary. E.g. although it looks like the space around the sprite name is a bit of a waste, it’s almost a perfect fit for the longest name. I think that in order to fix it properly it would need a complete rewrite, which is a bit beyond the scope of the changes I’m making at the moment (trying to focus on bugfixes for 5.22!)

It’s good that there’s a “full info” display available, but the problem is that “full info” now means a lot more than it did in the RISC OS 3.5 days. So I think it should really work a lot more like a Windows directory viewer, where you can control which columns are displayed, perhaps even with a header row to allow things to be compacted horizontally a bit better (e.g. so “16M” instead of “16M colours”). The display could also be compacted vertically by using horizontal lines to separate the sprites instead of what appears to be a full blank text line, and/or using one line of detail text instead of two (one line would be pretty much mandatory if column headers were added)

Here are two layouts that I’ve come up with for the sprite info display. I think I prefer the tall one over the wide one.
[…]
Anyone have any opinions?

My vote is also for the tall version rather than the wide version. It just seems easier to find all the information in it. Thanks for your work on this Jeffrey!

The same…

Another vote for the taller dialog. Looks great :)

I think that in order to fix it properly it would need a complete rewrite, which is a bit beyond the scope of the changes I’m making at the moment

Fair enough!

I’ve now recreated the bounty proposal page. I’ve made a few changes compared to Michael’s post further up the thread:

• Clarified “Handle alpha masks”, etc. to state that we’re interested in creating those kinds of sprites. Technically !Paint already does handle them, if you ignore the bugs that I’m in the process of fixing. And editing of alpha masks/channels is mentioned further down as well. So it’s just the ability to create them which we’re missing.
• Mention CMYK as well (as long as kernel/SpriteExtend support is already there)
• Removed mention of the sprite info dialog and replaced with the enhanced “full info” display
• Add idea of being able to tint the brush sprite by the selected colour when “shape” is unticked
• Add a couple of ideas for spray can improvements
• Remove colour picker slider crash bug (was fixed a few weeks ago)

That looks good to me.

Question to ROOL: Can this be added to the official Bounty list now? Might be good to try an attract some interest from a developer.

Having tried to use !Paint to do a few things recently, I would have found it useful
to flip/rotate a selected area of a sprite and to be able to merge or import sprites.
I ended up having to open alll the sprites I wanted, do a screen snapshot and then work on that.
(Which was really awkward as I was working on RPi at the time and all my sprites were 16 colour. Had to transfer everything to RPCEmu and back.)
Also I think there may be another minor bug.
Create a sprite file with two sprites.
Use Menu/Display/Full sprite details.
Now arrange window so sprites are listed side by side. (Good resolution required)
Double click on each sprite to edit, then Menu/Edit/Mask on each.
The information displayed only updates when the first sprite is operated on or the window is redrawn.
The effects seem even more random with 6 sprites placed 3 wide.(1920×1080resolution)

The information displayed only updates when the first sprite is operated on or the window is redrawn.

Yep, I can recreate that issue here. It looks like it assumes the sprite file window only contains one column of sprites. Should be an easy fix!

Fix now checked in, along with all the other changes/fixes I was working on.

Feedback/bug reports welcome!

I’ve had a quick play. The sprite info looks great, and it’s also nice to see Mask ECF pattern working as it should in all modes. Great stuff!

I’ve created a new bounty for Paint improvements. Please let me know if the description text needs changing in any way.

Bump! 3,921 views of this thread, 22 voices and 129 posts. Two days after going live with this bounty, £0 of donations.