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
Has anyone noticed that iop.rpxl, which is the trap #3 call (d0 = $72), to
read/scan a pixel, is not implemented on the current versions of SMSQ/E?
The entire code seems to be:
moveq #-15,d0
rts
George
___
QL-Users Mailing List
gdgqler wrote:
Has anyone noticed that iop.rpxl, which is the trap #3 call (d0 =
$72), to read/scan a pixel, is not implemented on the current versions of
SMSQ/E?
The entire code seems to be:
moveq #-15,d0
rts
Only in the high colour modes, where the API is difficult to apply
anyway.
Marcel Kilgus schreef:
gdgqler wrote:
Has anyone noticed that iop.rpxl, which is the trap #3 call (d0 =
$72), to read/scan a pixel, is not implemented on the current versions of
SMSQ/E?
The entire code seems to be:
moveq #-15,d0
rts
Only in the high colour modes, where the API is
François Van Emelen wrote:
Isn't that the reason why 'RPXL% (Easyptr) doesn't work correctly?
Sure. But it's been this way for exactly 10 years now ;)
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
On 19 Feb 2010, at 11:52, Marcel Kilgus wrote:
Has anyone noticed that iop.rpxl, which is the trap #3 call (d0 =
$72), to read/scan a pixel, is not implemented on the current versions of
SMSQ/E?
The entire code seems to be:
moveq #-15,d0
rts
Only in the high colour modes, where
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 make much more sense, yes. But
nobody has touched it
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 but ended up
having to read
13 matches
Mail list logo
