[Ql-Users] Read Pixel Colour
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 pixels from the screen in my code - is this something that should be done in atomic mode so all is done and dusted before another program intervenes? Anyway, I found out the hard way that the code has to allow for different display modes! Christopher Cave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Read Pixel Colour
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 since Tony did it this way in 1999 or so... Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Read Pixel Colour
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 the API is difficult to apply > anyway. It could be slightly redefined to make more sense, but does > anybody *really* need it? 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. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Read Pixel Colour
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
Re: [Ql-Users] Read Pixel Colour
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 difficult to apply anyway. It could be slightly redefined to make more sense, but does anybody *really* need it? Marcel Isn't that the reason why 'RPXL% (Easyptr) doesn't work correctly? François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Read Pixel Colour
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. It could be slightly redefined to make more sense, but does anybody *really* need it? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Read Pixel Colour
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 http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] unsubscribe
unsubscribe - this (gobo...@tiscali.co.uk) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm