Bounty proposal: Paint

There is also a “prepare sources” script included with the OS source tarball which copies bits of the DDE into the source tree.

Yeah I think that’s what confused me a bit – the directory structure created by Prepare.!Run seems partly the same as the one in the DDE zip which made me think I should unzip the bought DDE into there, but I guess it doesn’t care where it runs from as long as you set the Build Directory correctly.

Ah hang on, are you saying if the DDE is already installed into the root, Prepare.!Run will afterwards copy bits of it into the source tree as well?

Ah hang on, are you saying if the DDE is already installed into the root, Prepare.!Run will afterwards copy bits of it into the source tree as well?

More exactly, if the DDE has been “seen” then running through the Build install/prepare sequence will copy bits across. If the DDE hasn’t been “seen” the Build install/prepare sequence complains about it.

Where the DDE actually is is pretty irrelevant to that process.

Thanks Steve.

Well I made a start on this Bounty this evening. I’ve got some code working to make the spray tool rate take into account the CPU speed which seems to work fairly nicely on RPCEmu. I’ll dust off my old Acorn hardware at some point to see how that performs with it.

After this I’ll probably try one of the more technical bits and if that goes well I’d say this Bounty could be marked Underway. :) I’ve not tried to contact ROOL directly about this yet as I wanted to get set up and see how viable it is first.

Hi everyone. I’ve been thinking about how I’m going to approach some of the items on this Bounty and I wanted to get your thoughts on my ideas about the “Full Info” Sprite File Window display.

Earlier in this thread Jeffrey said:

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)

I agree a sort of tabulated layout (a bit like Windows Explorer) is the way to go but I think the columns need to be static (as in not user resizable). In Windows they’re resizable with mouse drags and I don’t think there’s a standard RISC OS table control that can do this, is there? The header row will definitely save lots of space (“has mask” can just become “Mask” and “Y” or “Yes” for example) and I can write some code to auto-shrink columns when the text is short. Add to that menu options to deselect some of the columns and how about putting a horizontal scroll bar on the Sprite File Window?

Does this sound about right?

Does this sound about right?

Makes sense to me. :)

Makes sense to me. :)

Ah thanks! I was beginning to think I was talking to myself, but then I do talk a lot and maybe I ask too many questions. Or maybe these are questions I should be putting directly to ROOL, given that the bounty is already defined.

Well I made a start on this Bounty this evening.

Yay! Good news. It’s nice to see this being worked on – will encourage me to contribute some more to it :)

I agree a sort of tabulated layout (a bit like Windows Explorer) is the way to go.

Sounds sensible to me too. I think there’s lots of potential for rationalising the display a bit. I wondered about having the info for each sprite on two rows, making something like this possible:

Name        Colours         Dimensions       Features        Compatibility
--------------------------------------------------------------------------
Sprite1     256 colours     100 x 100 px     No mask         Mode 28
            BGR             90 x 90 dpi      Fixed palette

Sprite2     32K colours     100 x 100 px     Alpha mask      5.22 format
            RGB             45 x 45 dpi      No palette

Although that’s quite a departure from the current style, so maybe best to take one step at a time…

Or maybe these are questions I should be putting directly to ROOL?

I don’t think there’s any reason not to have discussions here about features, etc, but if you do formally take on the bounty I’m sure ROOL will be happy to answer questions. I think it would be great to see some changes to Paint, and would be very happy to test out changes if that’s helpful.

Although that’s quite a departure from the current style

Perhaps one of the queue of other people working on Paint would care to contribute to that aspect.
Oh, no queue…

I wondered about having the info for each sprite on two rows, making something like this possible

That’s not a bad idea, thanks. I’ll have a play about to see what fits best on the screen.

I don’t think there’s any reason not to have discussions here about features, etc, but if you do formally take on the bounty I’m sure ROOL will be happy to answer questions.

I’m currently waiting to hear back from them, but I know they’re busy.

I think it would be great to see some changes to Paint, and would be very happy to test out changes if that’s helpful.

Thanks :)

I made some small changes to the UI of Alarm a few months ago, and ROOL made it clear that all the windows must still work at a 640 × 480 resolution. This restricts the possibilities, and forces you to squeeze as much into a small window as possible. This explains the way Paint looks today.

If you do want to do tabulated display (and I think it’s a great idea), you’ll probably have a hard time getting it to work at the low resolution above.

Just a heads up for you.

That’s OK. I’ve been dropping to Mode 15 and 12 (so 640 × 256) while testing the UI (not really made any permanent changes to that yet), so if it fits on there it should fit on almost anything. :)

all the windows must still work at a 640 × 480 resolution.

That may seem ridiculous in this day and age, but remember that most of the ARM boards offer some form of analogue video output – I used my Pi with composite until I got myself the HDMI adaptor, and still the s-video connection is the only thing reliable on my Beagle (it or the adaptor don’t like each other). There was one window (configuration?) that went off the screen and it didn’t behave very well…

This restricts the possibilities, and forces you to squeeze as much into a small window as possible.

Unfortunately yes, but maybe the trick in some cases is to push some information off to other windows rather than trying to stuff everything into the one? To give you an idea – while it may be nice to have the full info option in Paint tell you all sorts of things like the image dpi and what machines a sprite is compatible with, do you really need that degree of information always visible? The dimensions and colour depth (and mode, if an old sprite) plus some sort of indication of whether it has a mask and custom palette (icons take less space than words here) are sufficient for most cases. For accessing the full information, perhaps Ctrl-Adjust or some other unused keypress could pop up a transient window that contains all the gory details?
Certainly, Paint’s UI could do with some revision, it’s a bit of a pain in the ass to call up the tools and palette, for instance. If you’re using a smaller screen, or working on multiple sprites, it is nice to be able to toggle them visible and not.
I’d suggest also including the sprite name in the tools and palette title bar so if multiple are open and you select to draw with pixel plot, you don’t end up nuking a picture with flood fill because, yeah, wrong tool panel, it’s the other one dummy, no not that one the other one. ;-)

I’d suggest also including the sprite name in the tools and palette title bar so if multiple are open and you select to draw with pixel plot, you don’t end up nuking a picture with flood fill because, yeah, wrong tool panel, it’s the other one dummy, no not that one the other one.

The tools window is global in ROOL Paint, thankfully. I think you’re thinking of ROL Paint, where they hung the tool panel off the side of each sprite edit window, which was awful, because different sprites had different tools selected.

I suggested earlier in the thread that editor windows could have a NetSurf-like status bar, showing the current foreground/background colours and an icon to open/bring-to-front the tools window.

One thing that the bounty does not specify is the export capability from !Paint. I think save as JPEG and save as PNG should be added. That would make the bounty proposal more attractive (to those who donate, rather than those who have to implement it)…

I agree that saving to PNG is sorely needed. I’m not too concerned about JPEG though as it’s aimed at photos and doesn’t work so well for the types of images that are typically stored in sprites.

I agree that saving to PNG is sorely needed.

Does this imply direct loading of PNG images as well?

Loading would indeed be good too :)

Loading would indeed be good too :)

I think that what was at the back of my mind there was the difference between ‘saving as’ and ‘exporting as’.

One wouldn’t want to save one’s masterpiece as a PNG, then be unable to load it back in to edit it, but exporting it as a PNG but still having to save it as a sprite or lose it would do the same thing. That is, exporting as PNG won’t set the ‘saved’ flag in the program.

I agree that saving to PNG is sorely needed. I’m not too concerned about JPEG though as it’s aimed at photos and doesn’t work so well for the types of images that are typically stored in sprites.

Guys these features would be good to have at some stage, but at the moment I have started coding the existing items and am not sure I like the idea of chasing moving goalposts, unless the donations keep coming in to match. I really wanted this bounty to be marked Underway but I have had no response at all to my e-mail to ROOL that I sent weeks ago. I don’t mind as I know they’re busy, as long as they get back to me eventually.

Doesn’t ChangeFSI handle JPEG or PNG?

I don’t think you need to worry Andy I’m sure ROOL won’t change the Bounty proposal at this stage.

Guys these features would be good to have at some stage, but at the moment I have started coding the existing items and am not sure I like the idea of chasing moving goalposts, unless the donations keep coming in to match. I really wanted this bounty to be marked Underway but I have had no response at all to my e-mail to ROOL that I sent weeks ago. I don’t mind as I know they’re busy, as long as they get back to me eventually.

Yup – agreed. The bounty is already a fairly daunting list of stuff to do, and it sounds very sensible to keep it at that. I’m sure ROOL will be in touch at some stage. They are very busy, and all volunteers, so it can take a while to hear back.

Doesn’t ChangeFSI handle JPEG or PNG?

Yes it does, as do PrivateEye and a number of other apps.

Regarding PNG export, I suspect this was done in the ROL fork by taking advantage of the generalised image file rendering and conversion modules. Starting on reimplementing those would be a separate bounty, but more useful than adding specific file format capability to single applications at a time.

Yes, I think a system wide image loader/saver that can work by trapping image file loads/saves would be better than every application having to reinvent the wheel. This way, an application only needs to know “sprite” and the translation takes place in the background.

Hi, I’ve had a go at adding some radio buttons to the “Create new sprite” dialogue to support alpha masks or alpha channels. I’ve also added radio buttons for the extra colour counts to be supported.

I’ve come up with two alternative UIs for alpha mask / alpha channel and we need to decide which is better please:

or

On the second layout I wasn’t sure what to call the regular 1bpp transparency mask. I went with “Transparency mask” to maintain familiarity with previous versions of Paint and to try to keep it easier to understand for non-techies, though “1bpp mask” would preserve more space on the window (I made the window wider, but if I bring the colour buttons onto three lines I can narrow it back down and fill in some of the space on the bottom right). What do you think?