Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Reply to thread

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.

 is a RISC OS UserRichardHallas on 07/03/05 3:57PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Delving inside a RiscPC emulator
    If emulation upsets you, look away now
     16 comments, latest by guestx on 27/1/06 1:41AM. Published: 20 Jan 2006

  • Random article

  • Cocognut freely available finally
    Don't tell the US Supreme Court [Updated]
     23 comments, latest by jess on 30/6/05 2:28PM. Published: 27 Jun 2005

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Leave young upstarts with a monopoly and you can easily end up with a badly focussed view of the world"
    Page generated in 0.1606 seconds.