bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] wrong dice colours in html export and below board in GUI


From: Jim Segrave
Subject: Re: [Bug-gnubg] wrong dice colours in html export and below board in GUI
Date: Fri, 28 Nov 2003 14:42:59 +0100
User-agent: Mutt/1.4i

On Fri 28 Nov 2003 (09:55 +0000), Jon Kinsey wrote:
> At 14:52 23/11/2003, Martin Janke wrote:
> >Hi,
> >
> >the colour of the dice in the html export images doesn't seem to be
> >correct. E.g. the yellow dice of the "dailygammon" board layout are
> >purple, the blue dice are grey.
> 
> I think I found the bug, here's the change if anyone is familiar with the 
> code perhaps they could double check my fix.
> 
> htmlimages.c
>        int dice_x = 3 * s * ( BEAROFF_WIDTH +
>                               3 * POINT_WIDTH +
>                               ( 6 * POINT_WIDTH + BAR_WIDTH ) * i )
> -        - 3 * ss * DIE_WIDTH / 2;
> +        - DIE_WIDTH / 2 *  3 * ss;
> 
> -      int dice_y = ( BOARD_HEIGHT / 2 * s - DIE_HEIGHT / 2 * ss ) * 
> nStride;
> +      int dice_y = ( s * BOARD_HEIGHT / 2 - ss * DIE_HEIGHT / 2 ) * 
> nStride;
> 
>         AlphaBlend( auchBoard +
>                     dice_x - 3 * ss * DIE_WIDTH +
>                     dice_y,
>         ...
> 
> Looks like the / and * were a bit mixed up causing occasional int rounding 
> errors - when the pointer is one out the reds change to greens etc.

Since C makes no promises about the order of expression evaluation, if
these changes make a difference, the code is broken, because it's
expecting the compiler to do something the compiler is not required to
do. 

ANSI C:

...
Except as indicated by the syntax[35] or otherwise specified later (for
the function-call operator (), &&, ||, ?:, and comma operators), the
order of evaluation of subexpressions and the order in which side
effects take place are both unspecified.
...

[35] The syntax specifies the precedence of operators of an expression
which is the order of the major subclauses of this subclause, highest
precedence first...

In the above subclauses, multiplication and division are in the same
subclause, so there is no precedence there. This leaves the compiler
free to evaluate:

3 * ss * DIE_WIDTH / 2 as any of:

(3 * ss * DIE_WIDTH) / 2
(3 * ss) * (DIE_WIDTH / 2)
3 * (ss * DIE_WIDTH / 2)

or to rearrange things at compile time:

3 * DIE_WIDTH / 2 evaluated in any order, replaced with the constant
result which gets multiplied by ss at run time.

Can we please insert parentheses where required to force the desired
evaluation (a comment as to why the parentheses are there would not go
amiss). Otherwise the above patch corrects the problem only courtesy
of the vagaries of the current compiler being used and could change if
another compiler or a later/earlier version of this compiler is used. 


-- 
Jim Segrave           address@hidden




reply via email to

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