Re: [Bug-gnubg] 3D boards

[Olivier Baur]

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.