David told us: "The save, print and plot functions have been disabled. The demo has all the additional features added to Release 8e and 8f - this is the upgrade version supplied with the Pattern Pack."
The zip also contains various example designs to play with. Given that engineering software is notoriously painfully to use, user interface wise, the demo should appeal to anyone concerned about RiscCAD's learning curve, and also how it compares to modern software. RiscCAD was returned to its author from its previous publisher last November, and in January, was re-released with updates and a hefty price drop.
I found that the demo borked up on redrawing as well. Adding the RiscCAD app to the list that SpecialFX keeps fixed the problem (with all of SpecialFX's options unticked for RiscCAD). This was on a SA RPC running Select. Looks like SpecialFX and RiscCAD don't like each other.
Yes, I see that RiscCAD and SpecialFX don't seem to get on with each other very well; I was investigating this very possibility when MooJuicey's comment appeared.
To cure the problem, load the SpecialFX setup utility in Configure and choose 'RiscCAD' from the pop-up 'Add' menu button at the top-right of the SpecialFX window (either pick RiscCAD from the list if it's running or type in its name manually). A new entry line will appear in the scrolling portion of SpecialFX's window. Turn off the switch in the first (V) column and click Save. End of problem.
Of course, you don't get nice anti-aliased lines in the RiscCAD window any more, but it's better than a scrambled display.
Loaded the demo into desktop mode.
played with it a bit, marvellous program
but you cannot quit it from desktop at all.
When you try to quit this from taskmanager,
it says: there is some uncached data, try
to fix this, but that is not possible, when
you say OK to window, it still do not quit,
the only way to quit the demo is to hard reset
your computer, yukkkkkkk.
The problem I had with the display on my quick go was the dimensions blurred. That is they were not erased as they were moved. Dragging another window over the top cleared it up. SA 4.39 SpecialFX running. I can confirm that SpecialFX should have a RiscCAD entry with the first Tick cleared.
There is quite definitely a bug in the Iyonix's implementation of the Draw module. Castle are aware of this but have as-yet not produced a fix. This bug affects ProArtisan 24, and it wouldn't surprise me if RiscCAD were another victim.
If in doubt search for 'iyonix draw module' on Google's usenet archive.
datawave: Do you have the FontFix module installed, perhaps? This is an earlier and less sophisticated version of SpecialFX, in effect, and can cause exactly the same kinds of problems to appear. If you do have FontFix installed, replacing it with SpecialFX would be a good idea because SpecialFX works on a per-application basis and can be turned off for individual problem applications, whereas FontFix is either all-on or all-off, system-wide.
Anyone who wants SpecialFX, incidentally, can download it from here (it's free, and source code is included):
Thanks Richard, I have just downloaded and run this, and guess what, it does exactly what people are reporting, lines everywhere.
I would suggest that users turn it off for RiscCAD at the moment. Now I can replicate it, I can have a look. Although I maintain that the fault is not with RiscCAD, as it only uses legal, and very simple Draw_Stroke commands.
I think more likely the fact that RiscCAD is probably the only program that rubber-bands objects in WYSIWYG mode (ie not using a thin line like other programs) that is causing the problem. I think GDraw is not taking into account the GCOL mode, which is set to 3 (EXOR) when rubber banding and is just ANDing to the screen. This is why the redrawn image is OK.
The AND vs XOR supposition is very likely to be the answer. I wasn't trying to suggest that there was anything 'wrong' with RiscCAD, by the way; this is just one of those things that can happen if you've got a slightly hacky piece of software like SpecialFX installed. I reckon that the benefits outweigh the disadvantages, as it's fine for the vast majority of situations (and you can turn it off for those where it isn't), but there can be minor side-effects like this with certain software.
SpecialFX redirects calls to the Draw module to CC's GDraw module in order cause anti-aliased lines to be drawn (if that particular feature is enabled), and for most software this works very well. Unfortunately, though, GDraw isn't quite a complete implementation of the Draw module; some of the more obscure Draw module features aren't duplicated in GDraw. Recent versions of SpecialFX have been updated to avoid certain known problems, but this is one of those situations that illustrates that a perfect solution isn't possible when the feature-set of the Draw and GDraw modules aren't 1:1 compatible.
It'll be interesting to see if David can work around the visual glitches by using thin lines. I suspect that this will probably work, but it'd be useful to know. (David: if this /does/ work, then maybe you could get the software to auto-detect whether SpecialFX - or FontFix, which does the same thing - is loaded, and rubber-band with thin lines if so... or use your existing method otherwise.)
I have felt VERY frustrated about SpecialFX at various times because it wrecked both applications I am developing: ArtWorks AND EasiWriter. It was a support nightmare to solve these problems and it cost me an enormous amount of time. Furtunately, two of the bugs that affected me have been fixed. The current version of ArtWorks still contains special code to simply kill SpecialFX and FontFix if it finds a version that interfers with ArtWorks and some code to switch off some SpecialFX functionality that still affects ArtWorks. I suggest you do the same in your !Run file. Everything will just cause people to blame your program. Just a warnings in a !ReadMe file does not help - instead, do it the other way round: Always kill the offending modules and put a note in the ReadMe advising users of this.
The problem you experience is 100% to be blamed on SpecialFX in that it diverts calls to GDraw that should not be diverted. GDraw works perfectly well, it just cannot be asked to do anti-aliasing under all circumstances. Most notably, it should be clear that anti-aliasing is totally pointless if the current GCol action is anything else but the standard OVERWRITE action. How would XOR'ed anti-aliasing look like? So, SpecialFX would have to be fixed to not call GDraw with anti-aliasing unless the GCol makes sense.
GDraw is a private module for exclusive use by ArtWorks and AWRender. These pieces of software know how/when to call it. If users want to run software that abuses GDraw by diverting calls to it from unaware applications, it is their risk...
The same goes for background blended font display, by the way: Some applications may have a reason for NOT wanting it - ArtWorks is an example.
You seem as frustrated as me in that users say "application X cannot do this...." when that is not the case at all.
I have put a fix in RiscCAD which detects the SpecialFX setting, and rubber-bands using thin lines if the SpecialFX setting is set to Anti-alias for RiscCAD. I am tempted to say that it really is nothing to do with me and why should I have to patch my program when it is working perfectly well.
As stated above, I am testing a work-around to allow users to still use SpecialFX, but in a way that does not cause display corruption. I will post new versions of !RunImage on my website (www.risccad.freeuk.com) when I have tested them.
I'm looking for a simple CAD program for a project I'm undertaking to convert a Unimog into an expedition vehicle which I am going to use to drive around Siberia. I haven't used RiscOS for a couple of years now, but after a fruitless search for a simple, easy to use, cheep 2D CAD program for windows this might provide a good reason to use RiscOS again. The only thing stopping me is the cost of VirtualRPC. Does anybody have a second hand copy of VARPC they would be willing to sell??
wuerthne: Martin, we've had all this before, both in public and in private, and I have no desire to have another argument about it. I do understand the frustration you must have felt in having to field a lot of support questions relating to a piece of software that, from your point of view, 'breaks' your own software, and I'm sorry for that - really. Similarly, I understand that from the point of view of purists, SpecialFX is not really a good idea because it's hack which, in effect, produce results that no-one ever envisaged. It makes software do what it was never designed to do, and when you're into that kind of business, you're almost bound to fall foul of problems here and there.
However, I'd like to make the following points:
1. In the documentation accompanying SpecialFX I make it abundantly clear that it *IS* a hack and that it *CAN* theoretically cause problems. I explain (in significant detail) what the likely problems are, and what to do about them. Anyone who installs SpecialFX should really familiarise themselves with the sorts of problems that the software can potentially cause, and try turning it off in the first instance rather than firing off a complaint. (That's easily said, I know; it's human nature to complain first and think later.)
2. For the *vast* majority of software, it provides a tremendously valuable improvement in on-screen display quality, and often bitmap output to files, too. It only upsets a very small proportion of applications, and so - for me at least - the benefits outweigh the disadvanges by a very large margin indeed. In fact, I'd go so far as to say that I really wouldn't be without it; it makes a tremendous, positive difference to my own way of working.
3. To say that it's "abusing" GDraw really strikes me as putting things a bit too strongly. It's using it in a way for which it was not originally designed, certainly, but CC never had any objection to this in days gone by (yes, I did ask). And as I say, for many people the benefits will outweigh the disadvantages.
4. It's unfortunate that ArtWorks and EasiWriter (both Martin's projects) have rather suffered at the hands of SpecialFX; Martin has had a much more negative experience with SpecialFX than anyone else in the RISC OS market, I'm sure, and that's regrettable. However, I have to say that I am personally not in the least bit keen about Martin's own solution relating to ArtWorks, which just turns SpecialFX's text-blending feature off for ArtWorks, because it introduces deficiencies that are - for me - far worse than the problem that SpecialFX creates.
That is, if SpecialFX is loaded, it makes some text in ArtWorks go invisible (text which does not appear over another object). That's a nuisance, but if you know about it, you can work around it easily enough. But if that's happening, then SpecialFX is delivering two *very* useful benefits which are lost if it's turned off:
(a) it's making all text in the ArtWorks window use background blending, which really does give a *huge* improvement in many situations, such as if you're designing a poster with lots of text in it in ArtWorks;
(b) it allows the BMExport module to export images with anti-aliased text in them. This seems not to happen normally; if I want bitmap exports with anti-aliased text in them, I have to turn on SpecialFX (maybe it depends on the font size). This was *very* important when I was creating the RISC OS 5 filetype icons, with their text banners at the bottom: it looks awful if you have non-anti-aliased text there.
So I've disabled Martin's blanket fix in the !Run file of my own copy of ArtWorks; I'd much rather have the very minor problem that SpecialFX creates than to lose its benefits.
For other software, it's rare for there to be a problem, and if there is, then either SpecialFX can be turned off or the software can be adapted to cater for the situation.
demondb: I have no intention of suggesting that your code is at fault; I'm sure it isn't, and I'm sorry that SpecialFX causes a problem with your software. You're actually quite right: this problem /is/ nothing to do with you, and your software /is/ working perfectly well as it stands. But if you're able to work around it without just turning SpecialFX off, then you do get the benefit of a vast improvement to the quality of the output displayed in the window of your program. I'd have thought that this would be seen as a very useful improvement overall. It's a pity that you're having to do a bit of extra work, but at least you get a tangible benefit from it. (And, as I say, the majority of software is not adversely affected by SpecialFX.)
In general terms, I'm pretty much against having individual programs turn off SpecialFX by themselves. It has a set of user-editable defaults and settings that can be used to turn aspects on and off without individual applications needing to employ rather heavy-handed tactics like that. In the case of ArtWorks, my own feeling is that the fix is worse than the problem, in that it removes some very useful benefits in favour of fixing a problem that isn't particularly serious. I know that Martin feels strongly about this (with justification, I'm sure, especially from the point of view of providing support), but in general I'd prefer the few applications that suffer from this kind of problem to have a note in their documentation about SpecialFX, telling users to disable it themselves if they find the particular known problem to be a concern. It's one thing if there is no loss of benefits if you turn it off, but in the case of ArtWorks you do lose some benefits, so I'd prefer it to be up to users to choose the least worst solution themselves.
Finally, I also think it's worth pointing out that I've had emails from developers in the past who were delighted with the improvements that SpecialFX delivered for their software, and even adapted their code to take better advantage of it. (I'm thinking here in particular of a major RISC OS application, not just a little freeware program.) Horses for courses, but it would be wrong to suggest that all the feedback has been negative.
Anyway, these are my personal opinions for what they're worth. I'm putting them here just to state my perspective on the issue; I'm not trying to start a big argument or even pretend that everyone should agree with me.
The bottom line is just that people really ought to read the SpecialFX documentation before installing it. It's a really useful utility, and one of my own personal favourite RISC OS enhancements (I didn't write the module myself, so I can say that!), but yes, there are certain 'gotchas' related to having it installed, and people ought to be aware of them before using it.
Yes, but am I right in thinking this is now shipping by default with the Iyonix.
If so, I think there should be a larger warning than is obviously the case. For a few weeks I thought RiscCAD was broken. I didn't, but I could have, wasted a lot of time looking for a fault that was not there. Also, I may have lost sales as several people posted saying 'RiscCAD does not work correctly on an Iyonix'.
I understand what you are saying, and now RiscCAD is able to work with SpecialFX it can be used to improve the screen display (although it does slow the redraw speed down, so you pay your money and take your choice).
Richard: Sorry, I went over the top in my comment. It would probably have been more carefully worded in a news posting, but I hate writing comments online, so it came out rather harshly. There may be some good to come out of though - it prompted me to think about the issue again, and I think I have found a way to work around the problem, which might make ArtWorks compatible with SpecialFX's background blending and even allow ArtWorks to do background blending itself...
David Buck: SpecialFX is not shipping by default with the Iyonix - at least not in the sense of the program being installed (unless that has changed recently). As far as I can see, the program is supplied with the standard disc image, but the user still has to install it manually. So, in theory, users who have it know about it. Unfortunately, due to the seemless operation of the program, it is quite typical that it is forgotten once it is installed, so users do not normally consider it when encountering problems.
Perhaps SpecialFX could be modified to put an icon on the iconbar/a widget icon in the window furniture so at least it is obvious to the user they have it installed and allows them to turn it off with a (shift) click?
In my work programming systems for large financial institutions I more often have problems with poorly communicated functional wishes than desktop modules with unexpected behaviour.
However sometimes we bump into problems of external systems that ultimately prove to be the source of our problems (or rather the interaction between our system and the external system is the problem). These inevitably take longer to diagnose, and sometimes don't get fixed leading to heated discussions.
As Martin's last post shows sometimes such discussions lead to new solutions/workarounds being found, or at least the workarounds becoming better known.
True, except that this time, it was not the contents of the discussion but simply the fact that the topic was brought up once again that finally convinced me that the problems needed to be sorted out.
It was surprisingly easy! I have just added some code to Crystal to make it fully compatible with background blended text, so SpecialFX can now be used to switch background blending on for all text in ArtWorks - though there is no need to use SpecialFX beause the next version of ArtWorks will do it natively anyway... So, future versions of ArtWorks will only have problems with old versions of SpecialFX known to be buggy.
wuerthne: Thanks, Martin, but there's no need to apologise; I wasn't in any way offended by your comments, and I do understand the frustration you must have felt in the past because of support queries etc. caused by SpecialFX. The content of your post (and others), though, made me feel that I should say something positive in favour of SpecialFX! I acknowledge that it can cause problems, but it /is/ very useful.
Anyway, I'm delighted to hear that you've found a way of fixing the underlying problem, and will be incorporating background blending 'properly' in ArtWorks, because a native solution is obviouly far preferable to one imposed by other software, and background blending is something I've wanted in ArtWorks for a long time.
demondb: In fact, SpecialFX is supplied not just on the Iyonix, but also with RISC OS Select/Adjust. However, in both cases it is (as Martin says) supplied as an optional extra for you to install yourself if you want to use it. I guess it would be helpful for my online HTML document about SpecialFX to be bundled with the software itself... the only reason it hasn't been included to date is that I produced it relatively recently (i.e. the bundled versions with RISC OS 4 and 5 predate the online downloadable version). I'll probably send a new, updated archive to RISCOS Ltd and Castle soon, for use with subsequent issues. However, the HTML document is only really a 'friendlier' version of the text-based documentation that's provided already.
blahsnr: a widget in window furniture would, I suspect, be hideously complicated to implement, assuming it's possible at all. Something could possibly be done via the nested Wimp (though that would break compatibility with RISC OS 3), but I don't think it's possible to put a new tool up in the title bar area (unless my memory is failing me, it'd have to be associated with the horizontal scroll bar). So it'd be a rather ugly solution, and it would add clutter to lots of windows and interfere with the standard appearance of window furniture, almost certainly creating more confusion than it would remove. So no, I don't see that as a practical answer.
However, your other idea, of a simple icon bar icon, is not only feasible but already possible! SpecialFX comprises two components: the module itself (SpecialFX, written by David Pilling) and the setup utility that controls it (SFXSetup, which I wrote). SFXSetup is actually slightly unusual in that it's designed to be used both as a plug-in for Configure and as a stand-alone utility. It's particularly useful to have it as a stand-alone utility on RISC OS 3 systems, because of course the plug-in based Configure isn't available on those machines. Anyway, if run directly with a double-click on its icon (or via an application launcher or whatever), SFXSetup installs an icon on the icon bar and behaves exactly like any other regular desktop utility. If run through Configure, it behaves slightly differently (observing certain Configure behavioural guidelines and refraining from installing an icon on the icon bar).
So, if you want to have some visible indication that SpecialFX is present, all you have to do is to run SFXSetup manually, or indeed add it to your boot sequence. You'll then get an icon on the icon bar, which has the added benefit of giving you quick and easy access to the setup window without having to go through Configure.