Re: [Ql-Users] Read Pixel Colour
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 make much more sense, yes. But nobody has touched it since Tony did it this way in 1999 or so... The reason this came up is that someone now trying to use this trap asked me why he could not get it to work. George ___ 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 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 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! It is much easier to read pixels in modes 32 and 33 than 4 8. Hence there is not really a need for iop.rpxl for the higher modes. iop.rpxl can read a pixel. This is something I might want to do. But it also scans pixels to find a colour. What would that be for? George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Read Pixel Colour
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 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? IOW.XTOP is the way to go in this case. Anyway, I found out the hard way that the code has to allow for different display modes! As George said, I could see a need for a mode independent trap that's reading a pixel value back. The scanning... not so much. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Read Pixel Colour
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 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Read Pixel Colour
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 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? IOW.XTOP is the way to go in this case. Anyway, I found out the hard way that the code has to allow for different display modes! As George said, I could see a need for a mode independent trap that's reading a pixel value back. The scanning... not so much. Marcel 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. I'd use this in my graphics programs if it were implemented. I guess next question is does it return the 16-bit colour value as store din the video RAM, or if you are using pal modes (i.e. does it return 6 for yellow or the 16-bit value) and so on. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Read Pixel Colour
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 black is $0001 still black or does scanning stop there?). When doing a graphics program it hopefully has the image in an internal format it can understand. I'd suggest scanning this off-screen bitmap instead of on the screen (if the image doesn't fit on the screen, should the flood fill stop at the visible borders? I guess not). Anyway, I guess we won't see Photoshop for SMSQ/E anytime soon ;) 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
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
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
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
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
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
[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
