Enter Your Reply

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.