[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] 3D boards
From: |
Olivier Baur |
Subject: |
Re: [Bug-gnubg] 3D boards |
Date: |
Sun, 17 Aug 2003 21:21:03 +0200 |
Le samedi, 16 aoû 2003, à 20:41 Europe/Paris, Martin Janke a écrit :
And when it's gnubg's turn to play, it freezes once its dice are drawn
on the board; only the "Stop" button remains active
When I tried the 3d boards the first time, I had the same problem. In
the end it was just caused by the fact that the animation of gnubg's
move was so painfully slow that it seemed to be frozen. The animation
of
moving one checker across the board took minutes. (In my case the cause
of the problem was that the X-server on my linux box was not correctly
configured for 3D H/W accelaration.) What does "Settings -> Appearance
-> 3d-Options -> Test Performance" say?
The performance test also freezed gnubg.
I've found the problem: it comes from the get_time() function in
board3d/timer.c.
I think it expects that CLOCKS_PER_SEC == 1000000 (on million), which
is not always the case (see man page below). On my system, it is
defined to 100, and so time doesn't flow for the animation routines. I
could correct the problem by changing get_time():
return clock() / 1000.0;
to
return clock() / 1000.0 * (1000000 / CLOCKS_PER_SEC);
in boar3d/timer.c. Can anybody try this at home to check it doesn't
disturb a previously normal behavior, before the change is committed to
CVS?
Now, with these animations, I can't help playing games gnubg! It is
really great to see the dice rolling!
-- Olivier
From my clock() man page:
The clock() function conforms to ISO/IEC 9899:1990 (``ISO C89'').
How-
ever, Version 2 of the Single UNIX Specification (``SUSv2'')
requires
CLOCKS_PER_SEC to be defined as one million. FreeBSD does not
conform to
this requirement; changing the value would introduce binary
incompatibil-
ity and one million is still inadequate on modern processors.