Prev: ksh: /usr/bin/find: arg list too long
Next: Library requirement for mutex destroy
From: TR Oltrogge on 15 Oct 2009 15:58

<boltar2003(a)yahoo.co.uk> wrote in message news:hb7gtj$ocd$1(a)aioe.org...
> On Thu, 15 Oct 2009 11:33:26 -0400
<snip>
> Ah ok , so I guess I'd create a drawable 1x1 pixel , copy into that then
> do XGetImage and XGetPoint on that 1x1 drawable?
>
> You'd think that something like XReadPoint() would be an obvious thing
> to include since many other graphics systems had it but... oh well.
>
> Thanks for the info!
>
> B2003
>
BTW, I'm not an XWindow expert. I've written maybe half-a-dozen programs in
C (not C++) that call the Xlib routines
to write to the screen. I've never tried to read back into my program the
contents of a window since my program logic
wrote it in the first place and I know what it is (heh, heh). I run under
Linux, BTW, when I use Xlib because the development tools are
free and non-proprietary. I feel your frustration at not having "simple"
tools to read a window. But this is not a Commodore-64
world anymore! (Am I dating myself? I'm 62!)

Part of the complexity of XWindow is its power: the server for your XWindow
protocol requests *can* be running on a machine half way around the world
with display characteristics quite foreign to the
machine your client application is running on. The pattern of bits you pack
into a 'long' variable to define the 3 RGB colors
of a line, text, or pixel going into a drawable residing in the server's
memory can be rearranged by the server to best fit the
physical screen memory. But you'd like to think there was at least one
function to pull a pixel from the server's drawable and
then rearrange it to fit the usual pattern you originally packed into your
'long' variable. But I don't see any such function in my
O'Reilly & Associates "Xlib Programming Manual" Copyright 1992 book that I
have.

However, it does seem to have a
slightly simpler function that would eliminate your idea of having to create
a 1x1 pixel drawable and XCopy() your source
window into. Look at XGetSubImage(). This will permit you to pull a 1x1 (or
any size you want) sub-portion of your
game window into your pre-created XImage structure. Then you use XGetPixel()
to pull the pixel's color in client-side
'long' variable format. So, instead of XCopy(), XGetImage(), XGetPoint() you
would use XGetSubImage(), XGetPoint().

HTH

Tim


From: boltar2003 on 16 Oct 2009 04:28
On Thu, 15 Oct 2009 15:58:01 -0400
"TR Oltrogge" <troltrogge(a)verizon.net> wrote:
>window into. Look at XGetSubImage(). This will permit you to pull a 1x1 (or
>any size you want) sub-portion of your
>game window into your pre-created XImage structure. Then you use XGetPixel()
>to pull the pixel's color in client-side
>'long' variable format. So, instead of XCopy(), XGetImage(), XGetPoint() you
>would use XGetSubImage(), XGetPoint().

Even better, thanks for that.

B2003

First  |  Prev  | 
Pages: 1 2
Prev: ksh: /usr/bin/find: arg list too long
Next: Library requirement for mutex destroy