[Bug-gnubg] Parameterised board geometry

[Jim Segrave]

I was off work with a stomach flu, so I used the time to do some
mostly tedious repetitive editing.

I have just completed a first cut at 'magic number removal' and have a
verion of gnubg where the entire board structure is defined by the
chequer diamter, cube and die size and the amount of extra space to be 
included between the points. I've built a 72x108 board with this.
(Although examining the code indicates that this is not safe to use as 
it's not actually possible to place a die or doubling cube between two
opposing points with five chequers). The shortest board where this
won't happen is a 74x108.

My hope was then that I would be able to replace the #defined
constants with run-time calculated ones, and that I could generate
boards with the same aspect ratio (more or less) but using chequer
sizes other than multiples of 6 - for example a 144 x 110 using a size
8 chequer or 180 x 126 using a size 10 chequer. This might allow using
an optimal board size for space filling.

So far that part hasn't worked - the RefractBlend routine in
gtkboard.c blows up if I change the chequer size to 8, #ifdeff'ing
this call out still gives a board with all sorts of problem areas, a
blank stripe, incomplete rendering of the frame edges, etc. If anyone
else feels that they understand these routines, it would be nice to
get them working using #defines derived from fundamental definitions
of chequer size, otherwise I may keep grinding at them - my initial
work was simply to identify the easy constants related to board and
chequer size, the constants which will affect only a small number of
pixel rows/columns (like the edges of areas) are hard to identify and
relate to the overall geometry.

boarddim.h has the definitions - to change the height of the board
relative to the width, simply change EXTR_HEIGHT from 0 (for a 72x108)
to 10 (82 x 108) to whatever. Reducing the cube size doesn't work yet,
the number rendering seems to have the cube size hard coded, similarly
dice rendering with a die size < 7 doesn't work (didn't surprise me on
that). 

Very brief testing suggests that the 3d board stuff is unaffected by
these changes.

If the other constants can be found and parameterised, we may be able
to select fundamental board widths in steps of 36 pixels, so that
rather than using a single board format scaled in steps, we choose a
chequer size to give a maximal area board.  

The parameters in boarddim.h are not optimised, there are undoubtedly
redundancies in the expressions, but if everything can be reduced to
parameters derived from a few constants:

chequer size, die size, cube size, arrow size and extra space, 

then board geometry can be done at run rather than compile time.

-- 
Jim Segrave           address@hidden