Mmm, nice. Be able to test for regressions in display performance.
Thanks.
In changes just pushed ...
Add experimental support for tactical halos, which are arcs of circles
drawn near the edge of tactical, to express distance and bearing to
off-screen objects such as ships.
- not drawn in red alert,
- drawn every ten updates, so lag reality,
- dark green for our planets,
- light green for our team players,
- red for non-team (enemy) players,
- thicker for players with kills.
On Sun, Jul 06, 2008 at 12:09:09AM +1000, Stephen Thorne wrote:
> I have a problem on AMD64 figuring out the file descriptor of the X
> server. The current logic does some incredibly magical things using
> ctypes to dig into the X server to figure out which fd to attach to.
I think it is digging into the X library, actually, not the server.
The mysterious code came from the One Laptop Per Child project, where
AMD64 was not a consideration.
Pygame rests on top of SDL, and SDL rests on top of Xlib. Xlib manages
the UNIX socket or TCP socket connection to the X server.
Here is a guess as to what it does. I think it is looking into the
_XDisplay struct as defined by Xlib.h, which contains two pointers then
an int fd.
typedef struct _XDisplay
{
XExtData *ext_data; /* hook for extension to hang data */
struct _XPrivate *private1;
int fd; /* Network socket. */
... }
Therefore on AMD64 that last "n+8" should be "n+16" since the two
members of the struct immediately before the fd are pointers.
Working backwards ... here is where it gets doubtful ... I don't know
what
str(pygame.display.get_wm_info()['display'])[23:-1]
is other than it looks like an address in hex, presumably of something
that points to something that points to the _XDisplay struct.
Many people have asked pygame to expose their X socket file descriptor,
and that they haven't suggests it might be an SDL limitation.
--
James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/