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
Re: [Ql-Users] unsubscribe
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 address, Ql-users-q-v-d DOT com-request AT lists DOT q-v-d DOT com (replace the words DOT and AT of course with . and @) People always seem to put superfluous material in the unsubscribe emails, which prevents the system understandign what you mean. If you're a Quanta member, there was an article about this list in the Dec09/Jan10 issue. Dilwyn - Original Message - From: GO BOY GO-LT gobo...@tiscali.co.uk To: ql-us...@q-v-d.com Sent: Friday, February 19, 2010 11:17 AM Subject: [Ql-Users] unsubscribe unsubscribe - this (gobo...@tiscali.co.uk) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2695 - Release Date: 02/18/10 07:34:00 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
