Bounty proposal: Paint

I’ve had a look at some more of Paint’s code. Currently when you drag a palette file into a sprite window for an existing sprite, it counts the entries in the palette. It permits 16 or 20 entry palette files (and also 60 byte Arthur format palettes) to be loaded for a 16 colour sprite. For a 256 colour sprite, it only permits a 256 entry palette to be loaded.

If the palette file does not match the above criteria for the sprite, that message “Palette file doesn’t match sprite palette” gets generated.

How do I get the default 16 entry fixed palette for 256 colour sprites? Is it just the default palette Paint provides for 16 colour sprites? If so, I can just write some code to copy it into the sprite’s memory, as I can’t see any other way to create it for a 256 colour sprite.

Hi Andy,

I have now idea if RISC OS allows you to programmatically create a 16-entry-palette-256-colour-sprite, but I know how they are (or should be) interpreted by RISC OS code. 16 entry palettes are really a VIDC1 thing based on the limitations (only 16 palette registers available to define the 256 colours available) of VIDC1 technology.

It is important to know that 64 palette entry sprites are not displayed faithfully in VIDC1 world – only the last 16 palette entries are fed directly into VIDC1 palette registers, which determines what you really see on screen. Of course 16 palette entries also only work if all palettes are the same in VIDC1 world, so I don’t know if anyone ever sensibly used 256-colour-16-palette-entry sprites in a RISC OS 3.1 desktop.

Anyway – here is how it works:

• every palette entry is 12 bits, 4B 4G 4R (but you know that already ;-))
• every byte representing a pixel gets the following colour:
  • the lower 4 bits refers to the palette index (the “base colour” if you like)
  • the upper 4 bits represent additional colour information: 1 bit B, two bits G, one bit R

For the default palette, this then results in a byte representing BGGRBRTT, where TT is added to all R,G,B values at the same time.

Hope this helps…

That’s a helpful summary, thank you Steffen. The VDU chapter of the Archimedes Programmer’s Reference Manual is easier reading thanks to your post. That’s fascinating that they send the upper 4 bits of colour directly to the digital to analogue converter on the VIDC1 to combine with the palette colours. Clever stuff!

In summary, I think it would be wise to restrict “RISC OS 5 !Paint” to a true 256 colour palette. Allow import of 16/64 colour palettes, but calculate the 256 entry palette from them, which is what the user then sees. You remain backwards compatible for reading all valid sprite formats since the dawn of mankind, but you allow only creation/saving reasonably modern sprites compatible with RISC OS 3.5+.

If someone really wants to create old-style sprites, they can always start up their good old Arthur !Paint (or whatever it was called back then!) in the emulator of choice.

I think I’ve got what I needed to know now, thanks. With a bit of testing I’ve found I can reliably get the default 16 entry palette from Paint by creating a 256 colour sprite with no palette, then doing Edit→Palette. When that sprite is saved, its palette occupies 128 bytes (16 palette entries; 2 words per entry). Creating a 256 colour sprite with a colour palette, the saved sprite’s palette occupies 512 bytes (64 palette entries; 2 words per entry).^* That means I have everything I need to support both palette types as well as the full 256 entry palettes.

Steffen, for the sake of user friendliness, I’d be inclined to agree with you, but I’ve already spent some time implementing pop-up menus for the Create New Sprite dialogue to neatly fit on the “64 (fixed)” and “16 (fixed)” options, so I will go ahead and implement them. They’re under a divider on the menu as Chris suggested and they’re only selectable for 256 colour sprites, so hopefully they won’t cause too much confusion to new users.

^{*This is the behaviour edwardx described earlier in this thread, but you have to examine the sprite files to see it. Exporting palette files puts the palette data in what seems to be a different format to that used within a sprite. If I have time, I will grey out Edit→Palette for the “64 (fixed)” and “16 (fixed)” options and change it so it adds a 256 entry palette to 256 colour sprites with no palette.}

Just in case anyone’s curious what I’m up to, I’m still fiddling with pop-up menus. RISC_OSLib (which Paint uses) doesn’t support them (because its menus are opened only via a hard-coded middle button click) but what it does do is jump in the way of any menu you create yourself. The proper workaround seems to be to call event_clear_current_menu () before opening the custom menu, so that RISC_OSLib doesn’t associate the events with one of its previously opened menus.

I was amazed how little example code we have for pop-up menus. I suppose they were quite a new innovation when Acorn packed up. !SciCalc is the easiest to follow. There wasn’t anything using RISC_OSLib that had them, so it’s been an interesting little learning exercise.

The various palette formats for 256 colour sprites (256 entry, 64 entry, 16 entry, greyscale) are all selectable and seem to work. I just need to do a bit more testing of those. It’s still going to be a while before I can release anymore code, mainly because there’s a lot to tidy up.

I was amazed how little example code we have for pop-up menus.

If there was example code then hopefully there would also be fewer oddities (because people would tend to notice them while writing the examples). I don’t recall the exact names/details off the top of my head, but I remember having to create some sort of menu_entry object, then cast it to char* when adding it to the menu (because that’s what the veneer requires), only for the Toolbox to turn around and cast it back to a menu_entry again. Why not just have the veneer take a menu_entry in the first place?

Just in case anyone’s curious what I’m up to, I’m still fiddling with pop-up menus. RISC_OSLib (which Paint uses) doesn’t support them (because its menus are opened only via a hard-coded middle button click) but what it does do is jump in the way of any menu you create yourself. The proper workaround seems to be to call event_clear_current_menu () before opening the custom menu, so that RISC_OSLib doesn’t associate the events with one of its previously opened menus.

MakeModes is written on top of RISC_OSLib and has some pop up menus in its GUI. Perhaps you could have a nosey how it does it? They all look to use a common alter_monitors_menu() function which reads the icon position and offsets the menu as the Style Guide demands.

MakeModes is written on top of RISC_OSLib and has some pop up menus in its GUI.

Ah, I totally missed that one. Thank you!

Just in case anyone’s curious what I’m up to, I’m still fiddling with pop-up menus. RISC_OSLib (which Paint uses) doesn’t support them (because its menus are opened only via a hard-coded middle button click)

To respond to my own point about RISC_OSLib only opening its menus on a middle click, I see MakeModes uses the magic of wimpt_fake_event() to fake the middle click when the pop-up menu icons are left clicked. A little convoluted, but effective!

Michael:

- When cropping/resizing have a dialog box to allow you to enter how many rows/columns to add/remove from each side

Compo has the best interface I’ve seen for this.

Could you share a screenshot of this interface? The demo of Compo I downloaded seems to want RISC OS 3.7. I only have 3.11 and 5 readily accessible at present, and it wouldn’t run on 32-bit.

However, I had a look at Compo’s templates and wondered if you meant this Trim dialogue?:

If so, it looks like that can only reduce the size of the sprite and not increase it. Is that right? I do like the cross shape with the four text boxes though.

I’ve made a couple of designs for this feature of Paint:

- When cropping/resizing have a dialog box to allow you to enter how many rows/columns to add/remove from each side

This interface is probably the easiest for users of Paint to understand because it’s using the familiar terminology of inserting or deleting rows and columns:

It’s a bit crowded, especially with the pop-up menus (to toggle insert/delete) but radio buttons would take up even more space and I think they have to be there. When you click the arrows near the top left of the dialogue, the controls to insert/delete rows/columns would update automatically.

If it was something I was coding just for myself, or for advanced users only, I’d just use this instead:

The X and Y Offsets control how the existing sprite is positioned on the newly resized canvas. They would update automatically when the arrows are clicked. For example, if you clicked the leftmost arrow to add a column to the left of the sprite, X Offset would increase by 1. Other painting programs use something similar but it’s typically in combination with a diagram of the effect on the image layout, so I think this interface is too confusing for Paint and the first one is preferable.

What do you think?

The second proposed interface is a little like the one from The GIMP (I just checked), however as indicated there is a preview of the effect using a miniaturized image and a rectangle to indicate what is happening. Would it be too difficult to get this in paint? (I would guess so).

What about a filled (white) rectangle indicating the image and a black rectangle indicating what is actually happening instead of a miniaturized image?

The second one is smaller. But I’ll need to think about it each time I’ll use it. The first one is much simpler for my brain :)

“Insert/Delete rows/columns” is probably not needed.

What about a filled (white) rectangle indicating the image and a black rectangle indicating what is actually happening instead of a miniaturized image?

It’s possible but I’d rather not make it a carbon copy of GIMP’s interface. In the Style Guide and elsewhere in Paint there’s an emphasis on ease of use for someone non-technical and the Style Guide says to avoid using technical jargon (I notice the Print dialogue has “Corner x” and “Corner y” and elsewhere “columns” and “rows” rather than “pixels”) and I personally think this interface is a bit more technical. The black and white rectangles could work but it might not be immediately obvious to a new user what they represent, especially in cases where they don’t match the proportions of the image and offsets.

“Insert/Delete rows/columns” is probably not needed.

I think it is because otherwise the labels “at top”, “on left”, etc. aren’t part of a meaningful sentence describing an action. I tried a layout where each text box was labelled with “rows” or “cols” individually but the interface was so cluttered it looked really confusing and daunting. Information overload.

I think it is because otherwise the labels “at top”, “on left”, etc. aren’t part of a meaningful sentence describing an action. I tried a layout where each text box was labelled with “rows” or “cols” individually but the interface was so cluttered it looked really confusing and daunting. Information overload.

Perhaps that the rectangle could be in the center of the different text boxes?

I would go with:

Use the same name in the title as the menu entry – stops having to double check if you have followed the menu arrow correctly. The menu says adjust size and the window says adjust size.

Width and height fields are described by the names and the edge adjustment is described by the diagram.

The ok button should say what you are doing ie Adjust and you should have a cancel button.

Just my 2p.

Or possibly better still:

I really like that Colin! So are the numbers on Edge adjustment the coordinates of the resized sprite’s edges relative to the original (not coordinates of the original sprite’s edges relative to the adjusted origin)?

If you moved the left edge further left, so it went from 0 to -1 and kept the right edge unchanged as 640, Width would increase to 641, correct?

So are the numbers on Edge adjustment the coordinates of the resized sprite’s edges relative to the original (not coordinates of the original sprite’s edges relative to the adjusted origin)?

Yes they are relative to the original. If you adjust left or right coords the width is altered. If you adjust the width the right coord is modified relative to the left coordinate. Similarly for the top and bottom coordinate.

Opening the dbox always sets left and bottom to 0 and right and top to width and height respectively. Pressing Adjust on Cancel resets these values so that if you change them you can return to the original values. Pressing Adjust on Adjust normalises the Edge adjustment so that the edges are 0,0,width,height ie it acts as if if the window has closed and reopened after selecting Adjust.

Alternatively the edge adjustments could be relative to the edge so that initial values are 0,0,0,0 but otherwise it would work the same ie reduce the width to 636 would change the right edge to -4 and a change of the right edge to -4 would change the width to 636. Changes to the left hand edge also affects the width – but changing width doesn’t modify the left edge.

It may be useful to display the original size – maybe add it to the title eg make the title ‘Adjust size – 640 × 480’

Alternatively the edge adjustments could be relative to the edge so that initial values are 0,0,0,0

Easier to understand. -1 = delete 1 line; +1 ) add 1 line.

Alternatively the edge adjustments could be relative to the edge so that initial values are 0,0,0,0

Easier to understand. -1 = delete 1 line; +1 ) add 1 line.

Only if they’re distances measured radially from the centre of the sprite. If they’re x and y coordinates, -1 would add a line on the left hand edge but delete it on the right! Similarly, -1 would delete on the top edge and add on the bottom.

I would go with David’s method. Positive adds to an edge and negative removes from an edge. I think generally edge adjustment won’t be used I think just changing the height and width is the most common usage. Is it actually necessary to be able to change the edges? Couldn’t the same be achieved by cropping the picture then adjusting the height and width?

Is it actually necessary to be able to change the edges?

Given that there’s no obvious accurate method of cropping a picture in Paint, the ability to remove edges is something that I use quite frequently in Paint.

Use case – screenshots of windows. Basic windows are no problem, Snapper can handle those. But complex windows built out of parts, or with panes, often come out wrong. One must grab an area of the screen, then trim it down in Paint.

Changing the height and width is not specific about which edge is to be affected – this may be ok for a blank sprite, but for an existing sprite you normally need to adjust a specific edge. I would vote for -1/0/+1 as the adjustment for that edge – which would be reflected in width/height. Changes in width/height only affect right/top edges.