bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnubg] 3d speedup (and timecontrol) problem


From: Jim Segrave
Subject: [Bug-gnubg] 3d speedup (and timecontrol) problem
Date: Sun, 18 Jan 2004 00:23:40 +0100
User-agent: Mutt/1.4.1i

On Fri 16 Jan 2004 (09:49 +0000), Jon Kinsey wrote:
> I've added a new option which aims to improve the performance of the 3d 
> board when playing games on slower machines.  Note that browsing matches 
> and other actions won't be any faster.
> 
> This is aimed at people with none or slow opengl graphics hardware 
> acceleration.  Without hardware acceleration performance is normally 
> about 1fps, this isn't usable.  With this new option it might be usable...
> 
> I class slow 3d graphics performance as less than about 5fps, in theory 
> the improvement here should be the biggest.  In practice these cards may 
> have difficulty coping with the new code I've added...
> 
> After that "hard-sell" I'll just add that I haven't done much testing or 
> finished everything yet, so there's likely to be things not being 
> displayed and/or erased correctly in certain circumstances.
> 
> Anyway if the 3d performance is bad on your machine give it a try and 
> see if selecting "quick draw" in the appearance dialog helps (or works)...
> 
> Jon

A few things:

misc3d.c uses a macro max which isn't defined in any standard C header
         file

get_time() does:

double get_time() {
   return 1000*clock()/CLOCKS_PER_SEC;
}

Under Unix, clock returns clock_t. In Linux, this is a long. The above
line produces negative values for some calls to clock(). Since the
starting value is not specified, this can happen on any call. With the
multiplier of 1000, the range of potential negative values increases -
a value of 2147483 for example goes negative.
Under FreeBSD, clock_t is a unsigned long, which is not quite so bad.

This problem can happen for the time control routines as well. I'd
suggest changing the 1000 to 1000.0, so it might not overflow, and
casting the return from clock() to unsigned long. 

A deeper problem is that clock() returns the time for the process
making the call. Under Unix and X, that does not include time spent in
the X server. So my laptop, without graphics acceleration, spent 11
minutes and 3 seconds doing a calibration and concluded I have a very
fast 3d display at 573 frames/second. The real answer is under 3
frames second, but it's all in the X rendering, so that time wasn't
counted. I would assume time controls will also be far to generous
when rendering boards under X.

The 3d display is better, but still unusable, it takes 7 seconds to
move 17/22 and about 12 seconds to move bar/20
This could be a result of the completely miscalculated update rate.

-- 
Jim Segrave           address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]