Comments/Ratings for a Single Item

Before I invest in that, I would want to be sure that there are actually people that want to use this feature at all.

There's me for one. I don't use Winboard, because it has poor graphics, and I don't think it yet supports any games I'm interested in well-enough that I can't play with another program that has better graphics. For now, I prefer to use ChessV, which plays many games well and includes some of my own graphics with it. I have a good Shogi program that came in a commercial suite that also includes Chess and Xiangqi, though I prefer other programs for those games, such as Chessmaster and Coffee Chinese Chess.

The user base of WinBoard seems to be far more interested in the games they use it for, and how well and reliably it supports the rules of those, than in having multi-colored pieces.

Yes, probably because the poor graphics turn off those who care about such things. My point is that you can expand your user base by allowing easier customization options for graphics.

They don't use WinBoard for generating artwork to hang on their walls...

I don't use Game Courier or Zillions of Games for that purpose either, but I do like to use a nice looking board and piece set when I play a game.

The way you scale the entire board, if I could find similar function in the Windows graphics library, does sound like it might be very expensive. Doesn't anti-aliasing involve Fourier transforming the image back and forth? You would have to do that every time the board changes (i.e. every move). Anything CPU-intensive is a no-no in a GUI that run on the same machine as the engines. There are already people that are complaining WinBoard currently uses more CPU time than they can afford fo their purpose (wich is playing sub-second games).

I'm no expert on how anti-aliasing is done. I just use a function supplied by the GD library. But I can tell you it is done very fast, and I expect Winboard would have to do only between moves, not when it needs all the CPU power for calculating a move. Anyway, resizing boards is not as important as just allowing bitmap images to be used for boards and pieces. It makes a difference only for large variants that don't easily fit on the screen. Game Courier's boards and pieces are at a scale that normally fits the screen for most games and usually don't need to be resized.

I think the risk that there are people that say: 'I am not going to play Shogi, as the pieces have only a single color' is very small. They are either interested to play Shogi, and would do no matter what to achieve that, or they don't.

I'll still play Shogi, but if Winboard plays Shogi only with shoddy graphics, I will play Shogi with another program. The issue here is not whether people are sufficiently interested in Shogi but whether your program would be a more appealing option than some other program.

In fact there is a lot that can be done with just outline and inner color. The Xiangqi pieces you show are in fact just that. The outline and the (solid) piece symbol are one color, the inner regions another. The WinBoard system could easily handle that. You could have designed the Shogi pieces similarly.

Shogi is a good reason for including multi-color pieces. In Shogi, the promoted sides of pieces are normally red rather than black. This makes it easier to tell promoted pieces from unpromoted ones, and it is crucial when you are using a westernized set in which the promoted pieces use the same images as the unpromoted pieces.

To Rich:
Indeed, I think it is good to have diversity. There is no point whatsoever
in giving WinBoard and GC all the same capabilities, as one of them would
then be superfluous. The requirements for a GUI are entirely different
from the requirements for a game-play server. GC wil never make a useful
GUI for engine-engine play, and WinBoard will never make as versatile a
client to a server that can prepare html pages as a browser. In the areas
where the tasks they can perform overlap, it only enriches the world that
they are different. People can then choose what they like best.

I would very much like to have an easier way of scaling the size of the
display, but if it is computationally too expensive, the efficiency
requirement hould take clear priority.

I am a firm believer in the 'maximum flexibility, minimum usefulness'
principle. Therefore I refrain from trying to make WinBoard do everything.
If there are tasks that have too little in common with what there is now,
it would be of no benefit to cram those into WinBoard. I would, for
instance, never teach it the rules of Checkers, Othello or Go to make it
possible to use it as a GUI for those games. There is too little synergy
to make that pay off.

| There's me for one. 

The keyword in this phrase is 'one'... :-)

| I don't use Winboard, because it has poor graphics, and I don't think
| it yet supports any games I'm interested in well-enough that I can't 
| play with another program that has better graphics. 

Well, if that is your opinion then I am happy you do not use it. If there
are other programs with graphics that you like better, then I could only
win you over by providing similar graphics. That would be a total waste of
time, as I would be making something that apparently exists already.

I have absolutely nothing to gain by competing with other programs in
their own niches through mimicry. WinBoard is not a commercial program,
and I therefore don't care how small it user base is. What I care about is that it provides opportunities to its users that they cannot find anywhere else.

| For now, I prefer to use ChessV, which plays many games well and 
| includes some of my own graphics with it. 

I have no experience with ChessV, as it does not support automated play
against other engines. In the Unspeakable World Championhip 2007 it ended
well below Fairy-Max, but Gregory told me that this was an obsolete
version used without his permission, not representative of the strength of
current versions.

| I have a good Shogi program that came in a commercial suite that also 
| includes Chess and Xiangqi, though I prefer other programs for those 
| games, such as Chessmaster and Coffee Chinese Chess.

Well, nice for you. Just play the Kamikze Mortal Shogi with that one, then. But it is of no use to me, as the Shogi program is no doubt not capable of automated play against, say, TJshogi or GNUshogi, or to the Shogi engine I will be developing.

| Yes, probably because the poor graphics turn off those who care about 
| such things. My point is that you can expand your user base by allowing
| easier customization options for graphics.

Well, I have never heard any complaint about this before, and current
users are eager enough to complain about many other aspects they don't
like, so it doesn't seem to be true in general that perceived
shortcomings immediately deter them from using it.

| I'm no expert on how anti-aliasing is done. I just use a function 
| supplied by the GD library. But I can tell you it is done very fast, 

Very fast is a relative notion. Something that needs to be done 60
times in a 1-min game doe not have to be visibly slow before it starts to
soak up a sizable fraction (say 5%) of the CPU time. Correspondance Chess has other standards.

| and I expect Winboard would have to do only between moves, not when it
| needs all the CPU power for calculating a move. 

The problem is that in engine-engine games you always need all CPU power
for calculating move, as when it i not engine A's turn to move, engine B
should start thinking. Plus that these programs often want to think in the
opponent's time as well.

| Anyway, resizing boards is not as important as just allowing bitmap 
| images to be used for boards and pieces. It makes a difference only 
| for large variants that don't easily fit on the screen. 

Well, it doe to me, and many like me: a I have a dual-core PC I play two
games simultaneously, and would like to fit both WinBoard displays next to
each other, together with the control windows of the corresponding two
tournament managers. And soon I will have a quad (or, when I get my way,
even an octal core or dual quad)...

| Game Courier's boards and pieces are at a scale that normally fits 
| the screen for most games and usually don't need to be resized.

Yes, if you only want to have one game on screen, and not four.

| I'll still play Shogi, but if Winboard plays Shogi only with shoddy 
| graphics, I will play Shogi with another program. The issue here is 
| not whether people are sufficiently interested in Shogi but whether 
| your program would be a more appealing option than some other program.

Well, to some it is. To me it is. That is enough for me.

| Shogi is a good reason for including multi-color pieces. In Shogi, 
| the promoted sides of pieces are normally red rather than black. 
| This makes it easier to tell promoted pieces from unpromoted ones, 
| and it is crucial when you are using a westernized set in which the 
| promoted pieces use the same images as the unpromoted pieces.

Well, there is no red in the Japanese set I have, that's for sure. Using
the same image for the promoted and unpromoted piece is just bad design of
the piece set. By the same token you could represent all Chess pieces by
Pawns, and then complain how essential it is to have their heas rendered
in all different colors to distinguish a Knight from a Queen...
The built-in winBoard representation does not suffer from this. Promoted
pieces are clearly distinct from the unpromoted versions there. They look
like the piece they promote to, while stil betraying their origin.

|| There's me for one. 

| The keyword in this phrase is 'one'... :-)

I can only speak for myself, but I doubt I'm alone.

| If there are other programs with graphics that you like better, then I 
| could only win you over by providing similar graphics.

No, that doesn't follow. You could win me over by providing better graphics. Besides, all I want is the ability for me to provide you with better graphics. I am not asking you to provide any additional graphics. I have the graphics. I want the ability to use them with Winboard.

| That would be a total waste of time, as I would be making something that 
| apparently exists already.

No, it would not be a waste of time at all. The only programs with the kind of graphics capability I want are Zillions of Games and a couple Chinese Chess programs with customizable graphics. Everything else comes up short, even ChessV, because it doesn't use images for boards.

|| I have a good Shogi program that came in a commercial suite that also 
|| includes Chess and Xiangqi, though I prefer other programs for those 
|| games, such as Chessmaster and Coffee Chinese Chess.

| Well, nice for you. Just play the Kamikze Mortal Shogi with that one, 
| then.

That is not an option. It is a commercial program that only plays Shogi and does not include any graphics for the Kamikaze piece.

|| Anyway, resizing boards is not as important as just allowing bitmap 
|| images to be used for boards and pieces. It makes a difference only 
|| for large variants that don't easily fit on the screen. 

| Well, it doe to me, and many like me: a I have a dual-core PC I play two
| games simultaneously, and would like to fit both WinBoard displays next 
| to each other, together with the control windows of the corresponding two
| tournament managers. And soon I will have a quad (or, when I get my way,
| even an octal core or dual quad)...

Since Winboard already supports fonts, you do have the option of using fonts instead of rescaled bitmaps. Adding a new feature to your program does not force you to use it. And if you added the feature, you could avoid the need to rescale altogether by creating some smaller bitmap pieces.

| Using the same image for the promoted and unpromoted piece is just bad 
| design of the piece set.

That depends on the set. I would not use the same images for a Japanese set, and my Symbolic set uses different images, but the set I based on the Chess Motif font uses standard Chess piece images, and it makes sense for this set to just change the color for the promoted pieces.

| By the same token you could represent all Chess pieces by
| Pawns, and then complain how essential it is to have their heas rendered
| in all different colors to distinguish a Knight from a Queen...

No, what works well in moderation does not always work well when taken to an extreme.

| The built-in winBoard representation does not suffer from this. Promoted
| pieces are clearly distinct from the unpromoted versions there. They look
| like the piece they promote to, while stil betraying their origin.

I would not know if this is true, because Winboard would not let me make a single move when I tried to use it for Shogi.

|| I would like to start with integrating Game Courier with a game engine.

| If I understand you correctly, you would want this engine to run on the
| same computer that acts as server for GC.

If it could. Otherwise, it might be enough to call an engine on another server. But I do want to look into the possibility of running an engine on the server. I know this website runs on a FreeBSD server. Would Fairy-Max run on a FreeBSD server?

Right now, I need to know what the most basic steps would be. I need to know where to put the engine, what protocol to use to communicate with it, and how I could do this through PHP.

Muller, to get piece values at ~3% exactitude you would need to presuppose
that piece values are static properties. But they are really changeable
with regard to tactical and strategical context. This means that you would
probably have to foresee the future in, say, ten moves in order to get a
~3% exactitude. One obvious example is XiangQi. Chinese Chess masters are
hard pressed to reveal the relative values of pieces. Those pieces which
are completely lousy, like the elephant and the mandarin, are sometimes
very valuable while they provide protection for the general, function as
screens for the cannon, or can block enemy pieces. So, in a certain
context they become very valuable. Ten moves later, the elephant or
mandarin is useless. Probably, in chinese chess, only a human is capable
of evaluating a piece.
/Mats

M. Winther
| Muller, to get piece values at ~3% exactitude you would need to 
| presuppose that piece values are static properties. But they are 
| really changeable with regard to tactical and strategical context. 

Not necessarily. I always measure piece values in a well-defined context,
e.g. opening values, end-game values. Piece values are by definition
strategic quantities, I avoid starting in tactical positions, and for an
accurate measurement I average over many non-tactical initial positions
with similar peiece makeup. This usually gives quite consistent results,
when you keep the number of pieces and the total value of present material
approximately constant. (i.e. the difference of the performance of two
diffent pieces is hardly dependend on the details of the makeup of the
opponent or its allies.)

That piece values change as the board empties, because. e.g., Rooks get
more freedom of movement and Cannons can find fewer platforms, is
something that can be measured separately. If the piece values found for
the various qualitatively different situations differ, you can try to add
material-interaction terms in the evaluation. (The best known example of
such a term in normal chess is one proportional to the product of the
number of Bishops and number of Pawns, making the effective B-N difference
dependent on the number of Pawns.)

| This means that you would probably have to foresee the future in, 
| say, ten moves in order to get a ~3% exactitude. 

I am not sure what you mean by 'forsee the future'. By playing out the
game until checkmate or legal draw, I effectively make a Monte-Carlo
sampilng of all plausible futures. But it is important that the sample is
generated under conditions of reasonabe tactical accuracy, or you would
not be sampling a representative set of realistic positions, which then
would distort the results.

| One obvious example is XiangQi. Chinese Chess masters are hard pressed
| to reveal the relative values of pieces. Those pieces which are 
| completely lousy, like the elephant and the mandarin, are sometimes
| very valuable while they provide protection for the general, function 
| as screens for the cannon, or can block enemy pieces. So, in a certain
| context they become very valuable. 

I have not built an engine to play Xiangqi yet (I am in the preliminary
design stage now of an engine that could play Shogi, Chess and Xiangi with
arbitrary Chess men on boards upto 10x10.) So I have not done any
measurements for tuning. Quite possibly the material-interaction terms in
Xiangqi are much larger than in Chess, due to the peculiar capture mode of
the Cannon and the restricted access pieces have to the board. It seems to
me that the effects you describe can be described reaconably well by
cross-product terms of number of Cannons and number of other pieces. This
transcends pure piece values, but can be measured just as easily.

| Ten moves later, the elephant or mandarin is useless. Probably, in 
| chinese chess, only a human is capable of evaluating a piece.

Such a fast change is usually tactical, and then has little to do with
strategic piece values. Unles the strategic situation completely changed
in those ten moves, e.g. because all heavy material got traded, or all
hoppers got traded. But in that case such differences can easily be
expressed by terms that are proportional to the amount of heavy material /
number of hoppers.

I doubt if Humans could do this job better than computers. This is why I
would like to build a Xiangqi engine, so that I could do similar tests on
piece values as I am doing now for Chess.

| If it could. Otherwise, it might be enough to call an engine on 
| another server. But I do want to look into the possibility of 
| running an engine on the server. I know this website runs on a 
| FreeBSD server. Would Fairy-Max run on a FreeBSD server?

Fairy-Max is available in source (this is included in the WinBoard_F
download), and the source can be compiled both for Windows and Linux. You
have to define the macro LINUX to make it use a Unix-like call for reading
the clock. I suppose this would also work on FreeBSD.

| Right now, I need to know what the most basic steps would be. I need 
| to know where to put the engine, what protocol to use to communicate 
| with it, and how I could do this through PHP.

WinBoard engines are normal console programs that communicate in plain
text. So it is fairly easy to run them on another machine, using a remote
shell there to which GC connects.

| No, that doesn't follow. You could win me over by providing better 
| graphics. Besides, all I want is the ability for me to provide you 
| with better graphics. I am not asking you to provide any additional 
| graphics. I have the graphics. I want the ability to use them with 
| Winboard.

It would be very nice to add other graphics to WinBoard, but I want to
avoid unlimited bloating, so I think te requirements should stay within
reason. In particular I want to avoid providing a zillion different
mechanisms for doing exactly the same thing, especially if each of them
would only work in different situations. (E.g. colors working only with
bitmaps, and scaling working only with fonts.)

| No, it would not be a waste of time at all. The only programs with 
| the kind of graphics capability I want are Zillions of Games and a 
| couple Chinese Chess programs with customizable graphics. Everything 
| else comes up short, even ChessV, because it doesn't use images for 
| boards.

Well, non of the graphics code in WinBoard is of my own hand, but I have
taken a peek at it. At the WinBoard part at least. This code is platform
dependent, and the Linux version, xboard, has completely different code
for this. WinBoard has built-in bitmaps (2-color for black pieces, 3-color
for white, one of the colors being 'transparent') for each size, and
scalable tri-color font-based pieces which are customizable. Xboard has
2-color built-in 'bitmaps' (transparent + color; no outline), and
4-color 'pixmaps' (including the square in the 4th color, so that a
duplicate set is needed), both non-scalable, but both customizable.

I consider it a very undesirable that WinBoard and xboard are so different
here, but phasing out customizability options in which sers might have
heavily invested is something that is 'not done'. My prevference would
be to switch to a single, platform-independent graphics package and format
for internal use (built-ins), and convert the obsolete customization input
formats to this internal format. In WinBoard things basically lready work
that way, MicroSoft monochrome bitmaps being the internal format (using 2
layers to create the white pieces), and font-based rendering converting
the given font to such bitmaps.

In the WinBoard graphcs code, there seems noting that resticts it to
monochrome bitmaps; the number of colors is part of the bitmap definition
in MicroSoft format. I am not sure if the MicroSoft graphics library
supports transparent color. Currently this is emlated by anding and orring
bitmaps together, wchich in black and white has a well-defined effect, but
with multiple bits per pixel might not always do what you want. If a
solution can be found for this, there would be nothing against using
many-color bitmaps as internal format.

Such bitmaps would then also be suitable as customization input (like
xboard already does for monochrome bitmaps), PROVIDED an acceptable way
for scaling the user input to the current disply size can be found.

Of course people having very special desires that are to uncommon to make
it likely to be supported can always customize their own private version
of WinBoard by changing the built-in bitmaps, and recompiling it. WinBoard
is open source.

| That is not an option. It is a commercial program that only plays Shogi
| and does not include any graphics for the Kamikaze piece.

That is what I mean. If WinBoard were the only program that remotely
supports what you want to do, you would use it despite the perceived minor
shortcomings.

| Since Winboard already supports fonts, you do have the option of 
| using fonts instead of rescaled bitmaps. Adding a new feature to 
| your program does not force you to use it. And if you added the 
| feature, you could avoid the need to rescale altogether by creating 
| some smaller bitmap pieces.

Like I explained above, I don't want to add too many features aimed at
doing the same task.

| That depends on the set. I would not use the same images for a 
| Japanese set, and my Symbolic set uses different images, but the 
| set I based on the Chess Motif font uses standard Chess piece images, 
| and it makes sense for this set to just change the color for the 
| promoted pieces.

I don't understand this. Promoted pieces in Shogi move completely
different from their unpromoted counterpart, so the symbol for a
corresponding standard Chess piece would be completely different. I would
think it made sense to represent pieces that move the same by the same
symbol.

| I would not know if this is true, because Winboard would not let 
| me make a single move when I tried to use it for Shogi.

This is strange. Was that because you could not select Shogi at all,
because you had no engine? If you click 'view or edit games' in the
startup dialog, you should not need any engne, and it sould accept all
moves. Be sure to use board size middling or bulky if you want to see al
the pieces, though, as for Shogi, not all sizes have built-in bitmaps.

Muller, obviously you know the mathematics. But I question the relevance of
determining piece value to the decimal. The method I have used is to see
how well a piece fares in a Western piece context, e.g. how many moves
does it make compared with the other pieces (i.e. how useful it is).
Another method is when I pit the new piece(s) against a different army of
known pieces. If the result is equal after a number of games, then I
regard the piece as equally valuable as its counterpart in the other army.
So this is a practical testing method of determining piece values, which I
let Zillions do automatically.

I have found that when a piece is valued, perhaps, 2.5, or 3.5, then it
tends to converge around the piece value 3, e.g. the same as a bishop or
knight. The point is, namely, that the new piece can threaten exchange, or
vice versa. And the threatened party cannot withdraw for strategical or
positional reasons. Hence the piece values converge around the nodes of 3
and 5. Remember that also the formally higher valued piece can often
threaten exchange to achieve a positional or tactical goal. 

So, they are worth the same due to practical factors, while they are
*practically* interchangeable*. Obviously, in an equal army variant both
players can exchange the new piece, and the remaining position is still
equal. Hence, the new piece is equally valuable as a light piece. To
really introduce a different valued piece, then it must by pinpointed at
4, I suppose. 

I don't know if this phenomenon can be mathematically represented. It
depends on the piece congestion, i.e. size of board, and whether the
nearly equal valued pieces are long-shooting, i.e. whether they can easily
be used to make an exchange.
/Mats

M. Winther:
| Another method is when I pit the new piece(s) against a different 
| army of known pieces. If the result is equal after a number of games, 
| then I regard the piece as equally valuable as its counterpart in the 
| other army. So this is a practical testing method of determining piece 
| values, which I let Zillions do automatically.

This is essentially the same way I do it. (Except that I do not use
Zillions, but Fairy-Max or Joker80.) Try to set up nearly equivalent piece
combinations, by making as few substitutions as possible in the array
defining the context. If a side wins modestly, I give it additional Pawns
odds to swing the balance, and gauge the remaining difference compared to
the Pawn value.

| I have found that when a piece is valued, perhaps, 2.5, or 3.5, 
| then it tends to converge around the piece value 3, e.g. the same 
| as a bishop or knight. The point is, namely, that the new piece can 
| threaten exchange, or vice versa. And the threatened party cannot 
| withdraw for strategical or positional reasons. 

This effect is certainly present to a certain extent, but not as large as
you make it out to be here. A difference of 5 centiPawn often occurs, and
is very rea. Thi is well confirmed in normal Chess, where the value of the
first Bishop to be captured is 50cP (the B-pair bonus) above that of any
Knight. This can be based on GM games, and it is also what I find in
computer self-play. On 10x8 a 50cP difference exists between B and N even
in absense of other Bishops, and not telling the computer they were equal
caused a neary 100 Eo drop in playing strength in results against other,
unrelated engines.

But it is true that for much smaller differences, like 20cP or less, a
computer often performs better if you make it underestimate the
difference.

| Hence the piece values converge around the nodes of 3 and 5. Remember 
| that also the formally higher valued piece can often threaten exchange 
| to achieve a positional or tactical goal. 

The tendency to control willingness to sacrifice should not be tuned by
the piece values, but by the value of the positional goal.

| So, they are worth the same due to practical factors, while they are
| *practically* interchangeable*. Obviously, in an equal army variant 
| both players can exchange the new piece, and the remaining position 
| is still equal. Hence, the new piece is equally valuable as a light 
| piece. 

I am not sure what you want to say with this.

| To really introduce a different valued piece, then it must by 
| pinpointed at 4, I suppose. 

I think the B-N base-value difference in Capablanca variants clearly shows
that this is not true. Ignoring a difference of 50cP really causes a large
drop in strength.

| I don't know if this phenomenon can be mathematically represented. 
| It depends on the piece congestion, i.e. size of board, and whether 
| the nearly equal valued pieces are long-shooting, i.e. whether they 
| can easily be used to make an exchange.

All these effects are included in the empirical value determination by
playing games. Fortunately self-play results are not very sensitive to
wrong piece values (unlike playing wrong piece values against correct
ones, wich makes you take a big hit). So if the values change in later
game phases, so that values tuned to the starting position no longer
strictly apply, the results are not significantly corrupted by this. So
although it would be better to use an engine with  very advanced
evalution, taking material-interaction terms into account next to the
piece values, this is not strictly needed for measuring the piece values.
(But it would be essential for measring the more subtle interaction
effects; if these are not recognized at all, they are simply randomly
squadered, and an initial unrecognized advantages might not survive long
enogh to affect the result. E.g if you play paired Bishops against
unpaired Bishops (i.e. on the same color) with in engine that does not
score the B-pair, the first Bishop is very likely to be traded so early,
that the B-pair advantage does not get the time to affect the score.

Muller, it is interesting to note the 0.5 difference between bishop and
knight in Capablanca's chess. An untweaked Zillions regards the
difference as 0.523 in the beginning and as 0.446 in the middlegame. Both
pieces increase their dynamic value, but the value of the knight increases
more, having to do with the centralization of the knight. More than +0.5 is
regarded as a clear advantage, but I cannot accept that the party who
exchanges a knight for a bishop has almost achieved a clear advantage.

In my own slightly tweaked version the difference is 0.499(!) in the
beginning, but the difference is reduced in the middlegame, to 0.279. But
a 0.3 points difference is significant enough. I have always though of
this as a drawback to Capablanca's chess. That's why I invented the
Donkey and the Kwagga, which are equally valuable as a bishop on the 8x10
board.
/Mats

Does Zillions recognize and award the Bishop pair? Or do the values you
give represent an average of the paired nd unpaired Bishop?

Exchanging the first B (so you break the pair) against N+P turned out to be an equal trade in Capablanca. It seems strange that the difference goes down. Based on GM games in normal Chess, the B-N difference increases as more Pawns disappear (as one would expect towards the end-game), exact equality occurring if each side has 5 Pawns.

Hello Fergus.

I am of the belief a major issue that would need to be worked out, is
people determining what the protocols for communication will be and
agreeing to use them.

An approach I am seeing that could work, would be to break down each
action distinctly.  Selecting a position is one.  Then selection which
piece(s) in an position to move would be another.  After this, where to
move the piece(s) to follows.  Then you resolve the results of the action
of moving to (like a pawn promotion).  Then you see if there is any other
moves or a pass action.

Between the interface and the play area is each discrete actions that are
passed back and forth.

H. G.,

If you do add support for bitmap images to Winboard, you might want to do it with OpenGL, which is supported by both Windows and Linux. A good image file format to use is PNG. It's a cross-platform compressed lossless format, similar to GIF but capable of supporting true color images. Like GIF, it can support transparent images. Zillions of Games supports Windows bitmap images, and instead of having a transparent color, Zillions treats green (#00FF00) as transparent. Game Courier follows the same convention for when it can't make use of an image's transparency, such as when it is using it as a brush for drawing a single board image.

While it would be nice for Winboard to support customized graphics, I might be able to use Andreas Kaufmann's Winboard Adapter for Zillions with the games you write Winboard engines for.

|| I would not know if this is true, because Winboard would not let 
|| me make a single move when I tried to use it for Shogi.

| This is strange. Was that because you could not select Shogi at all,
| because you had no engine? If you click 'view or edit games' in the
| startup dialog, you should not need any engne, and it sould accept all
| moves. Be sure to use board size middling or bulky if you want to see al
| the pieces, though, as for Shogi, not all sizes have built-in bitmaps.

I have two installations of Winboard. One is Winboard_F, which had Fairy-Max but no Shogi engine. The other is your demo package, which includes a Shogi engine that shows the opponent's pieces as reversed. When I tried to move pieces with it, it rejected every move I tried.

Fergus:
| If you do add support for bitmap images to Winboard, you might want to 
| do it with OpenGL, which is supported by both Windows and Linux. A 
| good image file format to use is PNG. It's a cross-platform compressed
| lossless format, similar to GIF but capable of supporting true color 
| images. Like GIF, it can support transparent images. Zillions of Games
| supports Windows bitmap images, and instead of having a transparent 
| color, Zillions treats green (#00FF00) as transparent. Game Courier 
| follows the same convention for when it can't make use of an image's 
| transparency, such as when it is using it as a brush for drawing a 
| single board image.

OpenGL would suit me, as my purpose is to unify WinBoard and xboard as
much as possible. But it will be a major ndertaking, as I know little 
about the grapics code of WinBoard, and nothing about that of xboard, 
and  nothing about graphics in gneral at all. All programs I have ever 
written were text-mode console appications. So I hope that someone else 
that is better prepared than I am can do this job.

On the short term, I found out that there is a routine stretchBlt in 
the graphics package winBoard uses, which allows scaling of the entire 
board after it is put together. The results do not look too bad if the 
original bitmaps did not have thick enough outlines. Unfortunately it 
seems to totally mess up the color pallette of the background texture, 
apparently reducing the number of colors. I have no idea why it would 
do that... I am not sure scaling the entire board is a solution. With 
'animate moves' on it causes all kind of problems, and it would have 
to be done ~20 times for each move.

Scaling individual bitmaps might also cause problems. An anti-aliased
scaling blurs the edge of the symbol, and mixes it with the background 
it had during scaling. This would make it difficut to cut it out and 
copy it over a varying background. A solution might be to scale the 
symbols on two different backgrounds, representative of a light and a
 dark square, as well as on a white background. A floodfill of 
everything within the white would then define the contours of the 
piece symbol with some spillover due to the anti-aliasing blurring
the piece. But the spillover does not hurt if the too-large mask is 
used to cut out a symbol on an approximately correct background. On 
evenly colored background you would not see it at all, and most 
textures contain an element of randomness that would not make it very 
obvious either if an 'halo' of 2 or 3 pixels around the piece would be 
overwritten by some background that came with the piece. So after the 
scaling the same procedure could be used as now for the font-based 
pieces: a mask would cut a black hole in the background, and a multi-
colored bitmap exactly fitting the hole would be ORed into it. It
would just be a matter of preparing the required bitmaps in duplicate 
through scaling the originals, which needs only be done when you 
change board size.

Could you provide me with some Windows bitmap files for pieces, on 
which I could try this out? I only want to demagnify, as magnifying 
is likely to produce ugly results, so I would need pretty large format, 
something like 129 x 129 (the largest square size WinBoard supports). 
It should be possible to scale them down to a square size lke 33x33, 
so make sure all lines are at least 4-5 pixels thick.

| While it would be nice for Winboard to support customized graphics, 
| I might be able to use Andreas Kaufmann's Winboard Adapter for 
| Zillions with the games you write Winboard engines for.

This should in theory be posible. I did not really extend WinBoard
protocol when adding the variants, except adding some new variant 
names, and allowing variant FENs in the setboard command. So if the 
adapter implements enough of WinBoard protocol it should work. It 
might refuse to pass moves in Shogi notation, though, which would be 
essential for communicating with GNU Shogi. I believe that TJshogi 
uses normal board coordinates, though. Of course the adapter might 
still choke on files>h or ranks>8...

| I have two installations of Winboard. One is Winboard_F, which 
| had Fairy-Max but no Shogi engine. The other is your demo package, 
| which includes a Shogi engine that shows the opponent's pieces as 
| reversed. When I tried to move pieces with it, it rejected every 
| move I tried. 

That demo pack was made more than a year go on another PC as I have 
now. Problem is that I can no longer run the GNU Shogi it contains, 
so I cannot test anything. What happens when you try to move? Does 
WinBoard ignore it when you try to grab a piece, oes it complain that 
it is not white's turn, does it reject the move as illegal, or does 
it pass the move to the engine and does the engine then rejects it as
illegal, so that WinBoard takes the move back? Come to think of it, 
did you try to play the white pieces or the black? In WinBoard 'white' 
is synonimous for 'sente', so it expects white to start.

Anyway, if the only purpose is to see the piece symbols, just start 
up the most-recent WinBoard without any engine, and select 'File -> 
New Variant... -> Shogi'. Then you should be able to move for the
STM.

| Could you provide me with some Windows bitmap files for pieces, on 
| which I could try this out? I only want to demagnify, as magnifying 
| is likely to produce ugly results, so I would need pretty large format, 
| something like 129 x 129 (the largest square size WinBoard supports). 

I will need your email address. You can email me with it. I don't normally have pieces so large, but I just scanned my Chinese Chess pieces today, and I can either send you some scans at that size or at the size they scanned as, about 160 x 160.

Muller, I haven't bothered to figure out Zillions's piece evaluation
method. Of course, in the initial position the knight is placed at the rim
and threatens only 3 squares. Closer to the centre it threatens 8 squares.
I suppose this is why its value increases more than the bishop.

On 10x10 boards this is an even greater problem. The difference between a
bishop and a knight corresponds, perhaps, to a pawn. Of course, there are
important strategical aspects to this. One cannot trade a bishop for a
knight easily. 
/Mats

M. Winther:
| Muller, I haven't bothered to figure out Zillions's piece evaluation
| method. Of course, in the initial position the knight is placed at the 
| rim and threatens only 3 squares. Closer to the centre it threatens 8 
| squares. I suppose this is why its value increases more than the
| bishop.

Ah, OK. You were speaking on the very short term, after development but
before material got traded. I consider that positional evaluation, not
part of the piece values. In the opening the positional evaluation is not
a strategic feature: all pieces are placed very poorly, but the opponent
does also have no means yet to prevent you from moving them to average
locations. A minimax search from the opning will thus be able to reach
leaves where the piece placement is more typical, and the score of such a
search does properly include the strategic part of the positional
evaluation, where the evaluation of the single position would not.

If you have not figured out Zillions evaluation, how did you obtain the
numbers you quote? Does Zillions print its total evaluation of the root
position, or can one specify a fixed search depth and print the score of
that? In that case you could simply delete a Knight from one side and a
Bishop from the other, and note the score imbalance this creates (in, say,
a 10-ply search), and then delete another Bishop on both sides and repeat
the experiment, to see if the the imbalance is affected. In case 1 you
would have BB-BN, which involves B-N difference plus B-pair bonus, while
in the second case it would be B vs N, only dependent on the B-N
difference.

| On 10x10 boards this is an even greater problem. The difference 
| between a bishop and a knight corresponds, perhaps, to a pawn. Of 
| course, there are important strategical aspects to this. One cannot 
| trade a bishop for a knight easily. 

Well, so you trade it for N+P. Pawns are abundant, and in the beginning
usually the sole defendants of Knights. So opportunities for trades like
that occur often enough. The situation is not worse as in Capablanca,
where you would effectively lose a full Pawn on trading your first Bishop
for a Knight. If the Bishop gets worth even more, trading B+P vs R (about
neutral in Capablanca, for the first Bishop) would be a natural channel.

Btw, I doubt that 10x10 would really affect the Bishop value so much. It
is mainly the increased width of the board, allowing the Bishop more
forward moves, that causes its value to increase.

| I will need your email address. You can email me with it. 

Well, now you mention it, your e-mail address does not seem to work. I
sent you a piececlopedia article on it early this month, and got
comlpaints about it being undeliverable for more than a day. As I never
heard from it again, I can only assume it never arrived.

| I don't normally have pieces so large, but I just scanned my Chinese 
| Chess pieces today, and I can either send you some scans at that size 
| or at the size they scanned as, about 160 x 160.

Will that work (scanning)? If the background is not of absolutely constant
color, it cannot be flood-filled to create a piece mask for separating
piece from backgound. I'd rather have pieces designed with a paint
program than photographs. What is the largest size in which the
piece-symbol graphics (e.g. Alfaerie) are available?

Zillions always shows the current value of a piece if you right-click on it. It is easy to change the value by tweaking. Anyway, strategic piece values are problematic. The bishop pair, in closed positions, holds no advantage. A knight is often more valuable than a bishop in closed positions. A knight is regularly more valuable than a bishop in king + light piece endgames when all pawns are on the same wing. I doubt Zillions takes all this into consideration. This is Rybka stuff.

Together with Axiom, Zillions is quite powerful, although not very strong. Axiom is a universal game engine that works in conjunction with the Zillions of Games (ZoG) product. Specifically, Axiom consists of a ZoG plug-in DLL and a set of scripts written in the Axiom language. Similar to the way in which the ZoG 'zrf' language is based on the Lisp language, the Axiom language is based on the Forth language. Unlike ZoG, Axiom supports the ability for game developers to specify the AI and therefore it has certain capacities that Zillions lacks. 
http://games.groups.yahoo.com/group/axiom-system/
/Mats

| Zillions always shows the current value of a piece if you right-
| click on it. 

And apparently the positional value is included in this, as a Knight
clicked on g1 gives another score than when you cick it on f3? Does it
also report a different value for the Knight on g1 if you delete all Pawns
from both sides (turning the position from closed into open)? Does the
value of a Bishop clicked on f1 depend on if you delete the second
Bishop?

| It is easy to change the value by tweaking. Anyway, strategic piece 
| values are problematic. The bishop pair, in closed positions, holds 
| no advantage. 

It remains to be seen if this is due to a decrease of the B-pair bonus, or
simply a consequence of the drop of the Bishop base value in closed
positions cancelling the B-pair bonus. A lone Bishop is also inferior to a
lone Knight in closed position. Kaufman found that in GM play a Bishop is
worth 1/8 Pawn more than a Knight with 4 or fewer Pawns per side while
with 6 or more Pawns the Knight is 'slightly' stronger. Assuming that
the later would mean ~1/16 (I doubt he could see differences smaller than
that), it means the Bishop can lose 19 cP in a closed position, so 38 cP
for two of them. This is hardly less than the B-pair bonus.

| A knight is often more valuable than a bishop in closed positions. 
| A knight is regularly more valuable than a bishop in king + light 
| piece endgames when all pawns are on the same wing. I doubt Zillions 
| takes all this into consideration. This is Rybka stuff.

Well, end-games is a different matter. I agree tht to get accurate
empirical end-game values, you should actually use an engine that pays
attention to such details when generating the games. This is why I have
now started to design a variant-capable engine much stronger than
Fairy-Max (which is about the most minimalistic engine in existence). I
think most engines about 500 Elo below Rybka already pay attention to
things like this. 

But I would indeed be surprised if Zilions did. It should not be too
difficult to have a satisfactory general rule for this, upping the
Pawn-structure evaluation for spread Pawns if the opponent only has
short-range pieces. I doubt that Zillions has much Pawn-structure
evaluation in the first place. As I am mainly interested in piece values
in the context of normal Chess, with normal Pawns, I would like to do
these determinations with an engine that understands orthodox Pawns well
(scoring at least passers, (with bonuses for defended, or connected
passers), backward and isolated pawns.

| Together with Axiom, Zillions is quite powerful, although not very 
| strong. Axiom is a universal game engine that works in conjunction 
| with the Zillions of Games (ZoG) product. Specifically, Axiom consists
| of a ZoG plug-in DLL and a set of scripts written in the Axiom 
| language. Similar to the way in which the ZoG 'zrf' language is based

| on the Lisp language, the Axiom language is based on the Forth 
| language. Unlike ZoG, Axiom supports the ability for game developers 
| to specify the AI and therefore it has certain capacities that 
| Zillions lacks. 

Any sufficiently powerful language an be used to program an engine, and I
prefer to use plain C. Apparently the protocol used to interface between
the ZoG and its engines is an open standard. The problem is that people
have developed engines for this protocol, and adapters to connect WinBoard
engines to this protocol. But there are no alternative GUIs for this
protocol, or adapters that allow you to connect a ZoG engine to a standard
GUI. While (as far as I understood) it is actually the ZoG GUI that is most
wanting, as it is not able to play two different engines against each
other.

|| I will need your email address. You can email me with it. 

| Well, now you mention it, your e-mail address does not seem to work. I
| sent you a piececlopedia article on it early this month, and got
| comlpaints about it being undeliverable for more than a day. As I never
| heard from it again, I can only assume it never arrived.

Due to some change in the website, my email address got deleted. I reinstated it last night. It should work now.

| Will that work (scanning)? If the background is not of absolutely 
| constant color, it cannot be flood-filled to create a piece mask 
| for separating piece from backgound.

Yes, it works. See the new Chinese Chess preset I made for evidence of this. I edited the scans to make the background a uniform transparent green.

| I'd rather have pieces designed with a paint program than photographs. 
| What is the largest size in which the piece-symbol graphics (e.g. 
| Alfaerie) are available?

The size they appear in on this site is their largest size, which is around 40x40 to 50x50. If you need something larger, I could just use a Chess font with Ultimate Paint and make a few large pieces.

OK, Fergus, I sent you the piececlopedia article again, so you should have
my e-mail address now. Please send me some BIG multicolored piece bitmaps,
and the biggest Alfaerie available, then I will make a quick attempt of
brewing something with it. I am skeptical that 50x50 will be big enough.
Normally people that use WinBoard to play make its main window
screen-filling, which even on the narrow screen of my laptop gives 72x72
squares. When I want to display two Capablanca games side by side on the
monitor of my desktop, I use 49x49. I would consider that annoyingly small
if I had to play myself. So it seems that on the average, WinBoard will
have to blow up the graphics you can deliver by a pretty large factor, and
we should hope that the result will not be too ugly.