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
