On 19 Feb 2010, at 15:33, Marcel Kilgus wrote:
gdgqler wrote:
I cannot see a need for it. It is nice to know that it is
intentionally not used in SMSQ/E. However, the message that is given
if you do try it is faulty parameter, which is slightly confusing.
Ah, I see. Not implemented would
On 19 Feb 2010, at 15:35, Christopher Cave wrote:
There has been a problem with reading pixels using this trap for ever or
at least since display modes became richer. I asked about it in this
group a year or two back but this attracted no interest at the time. I
was trying to write a flood
Christopher Cave wrote:
There has been a problem with reading pixels using this trap for ever or
at least since display modes became richer. I asked about it in this
group a year or two back but this attracted no interest at the time. I
was trying to write a flood facility into my CAD program
I think that the pixel scanning might provide a way of speeding up a
FLOOD by cutting out some recursion BUT re entrant shapes might require
some care. Anyway as far as I can recall, I haven't written any examples
using this.
Christopher Cave
___
Christopher Cave wrote:
There has been a problem with reading pixels using this trap for
ever or
at least since display modes became richer. I asked about it in
this
group a year or two back but this attracted no interest at the
time. I
was trying to write a flood facility into my CAD program
Dilwyn Jones wrote:
The scanning could be used for flood fills. That's how they used to be
written in BBC basic many years ago, to find the extremities of a
colour area, so where to stop flood filling.
Yes, this makes sense with 4 colours, but much less with 16 or 24 bit
(when scanning for
To unsubscribe, see Bruce's website at www.q-v-d.demon.co.uk/smsqe.htm
Nothing in SUBJECT line, nothing other than UNSUBSCRIBE in the body -
no signature or nothing else apart from possibly a password you were
issued with when joining.
You can send joining/leaving instructions to the other
