Bounty proposal: Paint

“Has the jury reached its verdict?”

“Yes, M’lud”

I have just made a donation to the !Paint bounty, though to be honest, I don’t really need !Paint at all for my work. What I am interested in though is the ability to make Alpha blended sprites. I need to be able to get a PNG, convert to sprite and then render it to a window, anything which helps me do that is great.

need to be able to get a PNG, convert to sprite and then render it to a window

In this instance, I don’t think this bounty is going to help with any of those aims, as Paint is a sprite editor. It sounds like you want to convert a foreign file format to sprite and display it (presumably in your own application?).

It looks like this post does everything you need: pump the png through spr2png, open the resulting file and poke over the mode word, then call the appropriate OS_SpriteOp.

While ChangeFSI can decode PNGs (including alpha ones) no part of ChangeFSI knows what to do with transparency, even when handling its native sprite format. You can call ChangeFSI either as a BASIC library function (viz result%=FNChangeFSI(arguments)) if the rest of your app is in BASIC. If not you can call it as a command (viz *ChangeFSI -argument1 -argument2).

If you want to go a 3rd way, the backend to ChangeFSI’s PNG decode is a position independent lump of library code which you can pass a PNG data stream and get back raw pixels. At that level you’d still have the alpha values to play with. As ChangeFSI is written in BASIC it’s reasonably easy to see how to call the back end manually (it’s the file called CFSIpng within the app).

But in summary: spr2png and you’re done.

You lost me at ‘poke over the mode word’. I write quite a lot of C, but this is my first attempt on RISC OS, and the WIMP etc. is still pretty unfamiliar. I am happy to try the spr2png thing, so will do so when I can make time.

Just to get me going though, do you know anywhere I can lay my hands on a sprite with alpha blending? I could just try to render that to get me started.

Quick suggestion about the colour selection models in Paint: move the colour selection requests into a ColourPicker bounty.

Work towards migration to Toolbox for Paint (even if we had a ‘fudged’ use of Toolbox to just open a Toolbox ColourPicker and the rest continued to use WimpLib initially).

That would mean the colour picker options are not just open to Paint but to Draw and to other applications too. And good development of that would be quite a significant task in its own right (but one which would be cross-platform).

Can anyone advise how Michael Drake’s toolbars can be implemented in Toolbox? I see Ben’s reply for direct Nested Wimp calls – can it be done in Toolbox without going down to direct Wimp calls level?

Hi everyone! I’ve just signed up here because I might be interested in giving this Improvements to !Paint bounty a go. I’m an experienced C/C++ programmer who spent a lot of time coding on RISC OS in my (some would say misspent) youth, although back then it was mainly BASIC and a bit of assembler.

There’s a lot of features on that list aren’t there? I imagine it could take me many months to do them all, so maybe payment for a subset would be more realistic, but then this bounty has been there for years already, hasn’t it?

At this stage I’ve fallen at the first hurdle trying to get !Paint to compile. I downloaded the source from here https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Apps/Paint/#dirlist – is that the right version to use for this bounty?

Anyway, trying to build with the makefile resulted in complaints about lots of missing dependencies, most notably something called modulewrap and RISC_OSLib. As far as I could tell the files needed for these aren’t available online anywhere, so how do I even compile this?

I did find a RISC_OSLib module after much searching but it didn’t have the source files the compiler seemed to need.

I should mention that I plan to buy the DDE but I was attempting to build !Paint with Acorn Desktop C. Will the DDE solve these modulewrap / RISC_OSLib issues? If so, how?

Many thanks.

The RISC_OSLib source comes with the DDE, although it’s also available in CVS (I’ll edit this post with its location [Edit: See Rick’s post below :) ]). I’m not sure about modulewrap.

[Edit: The binaries come with the DDE, not the source. The source is in CVS though!]

Acorn Desktop C is now ancient and I’d be amazed if it’s possible to build Paint with it. It’s definitely possible to build with the DDE though; I’ve had a quick look at it myself and was able to get it to build.

I don’t think you’re building it correctly – shouldn’t modulewrap be used to turn an application into a “module” for inclusion in the ROM? That said, the shared makefiles are horrible when you want a simple build without the complications. Might be simpler to write a new MakeFile for building a standalone version.

FWIW, modulewrap is, IIRC, in the RISC OS sources. Try somewhere in Lib.RISC_OSLib, I think that’s where I saw it…

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Lib/RISC_OSLib/s/modulewrap?rev=4.10;content-type=text%2Fplain

Chris: Thanks. It’s actually Acorn C/C++ (Release 5) – still fairly ancient but I thought it might build Paint.

Rick: Excellent, thanks! I’ll take a good look at that. None of my searches brought that up. I didn’t know what modulewrap was as I could find no information on it anywhere(!) but your explanation makes sense.

I’ll have another go at building it and report back later.

The general rule with any OS component is that it will probably only build correctly when you have a suitable build environment present. The build environment will provide key header files, libraries, and tools which are used during the build process. IIRC the DDE comes with a general-purpose build environment that will be suitable for most components, but if you’re working with bleeding-edge features or platform-specific components then you’d generally want to grab an appropriate build environment either straight from CVS or from one of the source tarballs (e.g. DiscDev would probably be a suitable one for working on Paint – that’s used to build the hard disc image, which must contain a copy of Paint for the poor souls on RISC OS 3.5)

The technical notes section of the wiki has lots of information about the build system, although a lot of it is geared towards ROM builds rather than disc or individual component builds.

https://www.riscosopen.org/wiki/documentation/show/Technical%20notes

Although the old Acorn C compiler might build Paint, it is likely to create code that won’t run on modern ARM cpus, so you really will need the latest DDE.

This is a good point to highlight the bounty suggestion about making the DDE free to download – https://www.riscosopen.org/forum/forums/8/topics/4004

Here we have a new user (Welcome Andy!) keen to get involved, but who can’t without putting cash upfront. Not an encouraging situation.

Hi Bryan, thanks for the welcome! :) I’m more than happy to support our community by buying the DDE. As much as anything else, I was just waiting for pay day!

That bounty suggestion is a good idea although personally I’d prefer people make further donations to the software development bounties when they choose one thing to put their money on. Those who are serious about claiming a bounty will get the cost of the DDE back on completion then anyway.

Speaking of which, will ROOL put new bounties up as soon as some current ones are completed? It seems like nothing’s been added in a looong time but I hope that’s a deliberate policy (to stop things getting spread too thin?) rather than stagnation.

Jeffrey thanks very much. Now I understand why there were so many paths and variables it couldn’t find!

From memory, I think the old DDE was rather fond of using unaligned reads, and something else that upsets ARMv7.

Looking at the requests in the bounty, I’m wondering if it wouldn’t be better to rewrite something “based upon Paint” instead of adding modern features to an ancient program. I’ve often thought of this myself as I quite like Paint and think software such as PhotoDesk are over complicated. But I’m no good with the algorithms… :-(

I suppose a port of GIMP could satisfy some of those needs (has anyone attempted this?) but I’m not sure if it could be distributed by ROOL, given the GNU licence and then there’s the lack of Sprite support. There was also DA’s Picture. The advantage of Paint is that it’s very lightweight and so will run well on the oldest Archies. I imagine GIMP would be sluggish even on Risc PCs.

Anyway, I’m very much up for adding features to the existing Paint code. A total rewrite is a whole different matter, although as a much later step with enough donations and time, who knows?

I suppose a port of GIMP could satisfy some of those needs

Mmm, not quite what I meant. ☺

Mmm, not quite what I meant. ☺

Ha ha, I’ll say no more about that!

I’m wondering if it wouldn’t be better to rewrite something “based upon Paint” instead of adding modern features to an ancient program.

At this point I’ll just quote a passage from this old post:

It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.

There’s nothing wrong with tidying up old code to make it easier to maintain or to squash bugs, but rewriting from scratch tends to be more trouble than it’s worth. Modern IDEs make refactoring easier but I don’t know how much work it is to use one of those for RISC OS development! :)

As far as source code goes, Paint isn’t that bad. Acorn had the sense to write it in C, and it’s not like Paint really does much, so it’s not particularly hard to work on. The only fiddly aspect is that it uses Flex, but unless I’m mistaken that’s pretty much our only option when it comes to fragmentation-free heap managers.

Well said guys. If it ain’t broke, don’t fix it! When you think about all the hard work that goes into writing a software product, reinventing the wheel by throwing out all that code and starting again can be very inefficient and wasteful, but I see it time and time again in the software industry. Change for the better, if you’re sure it’s better, is good, but change for the sake of change isn’t, and that happens a lot in the modern world.

The source code I’ve looked at so far seems fine.

The flip side of the coin is time spent trying to put new functionality into old code, and all of the glitches and problems that this can create.
However, the main point is:

The source code I’ve looked at so far seems fine.

If you’re happy with the existing code, that is the important thing.

Good news! I bought the DDE and after much fiddling I’ve finally got Paint to build! My main stumbling block was figuring out that the Build Directory in Builder has to be one level above “castle” otherwise lots of scripts will complain. In fairness, it is all documented, but I read somewhere that the Build Directory should ALWAYS be “RiscOS”, which made me think of “castle.RiscOS” – incorrect!

It also wasn’t completely clear to me where to unzip the DDE to (i.e. root directory of the hard disc or into the castle.RiscOS directory? Or the Build Directory?) but it didn’t seem to matter as far as I can tell.

Anyway, now I can finally start churning out code. Yay!

It also wasn’t completely clear to me where to unzip the DDE to

The “NutPi” version of the DDE includes an installer, which puts it in the root (ie. you get a new directory called AcornC/C++ in the root). Presumably the zip version goes into the same place.

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