Comments/Ratings for a Single Item

Muller, if you work in C, then you can use the c2forth compiler to convert
to Forth. So, if you are going to write an intelligent chess engine, then
you can make  thousands of Zillions chess variants play better chess by
implementing an Axiom engine, which uses Forth.
/Mats

Yeah, sure. And if you write Piececlopedia articles in Swedish, you can run
them through Babelfish to translate them to English, and out come all the
great plays of Shakespear... :-)))

Fergus, I experimented a bit with a colored bitmap that I snatched from the
GC pages. The bitmap was only 35x40, though, so I put it in a square of
45x45, and I have to magnify it for any WinBoard board size larger than
'mediocre'.

The bitmap itself was nicely anti-aliased, with clean edges (no doubt
because you made sure the transparancy left no rags on the outside). The
graphics routine I use (StretchBlt) seems to do the (de)magnification by
sampling. For small demagnification factors this means it now and then
skips a scan line, making ugly dents in the piece outlines where these
make a small angle with the vertical or horizontal axis. If the original
bitmap would have been larger, this effect should becom much smaller, as
it always skips lines at these large demagnifications, and the difference
between skipping 2 or 3 lines is a lot less obvious than between skipping
0 or 1.

At the large sizes, it duplicates lines, leadng to a 'blocky'
appearence: te individual pixels are blown up to squares. This effect
would also disappear if we start from larger images.

It would be conveient if these larger images are already filtered so that
the upper 1/2 or 2/3 of the spatial frequency components would be
suppressed. This would make the larger sizes a bit 'smeared' in
apperance, but not blocky. The demagnified pieces will then automatically
be anti-aliased. Perhaps 100 x 100 would be a good size to start from.

If you want to look at the efect at different board sizes, I put a test
version at http://home.hccnet.nl/h.g.muller/color.zip . Note only one
piece is displayed, as I only built in one colored bitmap.

Game Courier got comparable results when enlarging, but it got better results when reducing the size. Compare:

Has the discussion shifted to a standardizing of graphic formats?  In other
words, one of the byproducts of this discussion could be that a client like
Zillions could receive a set of graphics from a server for a game, and use
it.  I do see this being worked out to be good.  We just need to get
buy-in.

I believe Mr. Muller meant to add this comment to this thread here:


'Game Courier got comparable results when enlarging, but it got better
results when reducing the size. Compare:'

Yes, indeed. The scaling routine seems to use some form of anti-aliasing.
I could achieve this in WinBoard by blowing up the bitmap by a factor 2 or 3, smoothen it, and then reduce to the desired size by sampling. But it seems a bit silly to do those first two step in WinBoard, every time you change the board size of piece set, as they are always the same. So it would be better to do them once and for all, and have WinBoard read in the smoothened large bitmaps, and perform the demagnifying StretchBlt on them to generate the desired piece size.

I must say I am not very pleased with either result. The anti-aliased
symbols look really ugly. Some black lines have a light-gray line running along them, which would have looked much better if it was background color. I think the true-type-font rendering is much more suitable for scaling pictures with sharp high-contrast edges and narrow lines, such as we are dealing with here.

I guess it would not be very difficult to create your Shogi pieces
through font-based rendering. The only thing that is needed is a more elaborate procedure to color-fill them. You could isolate the naked symbols printed on the 'chips' by flood-filling a number of times from the outside upto a specified color, to peel off the outer layers of the symbol until you reach the part you want to color, and then overprint with the symbol again to restore the outer boundary, and finally floodfill the outside to make it transparent.

| I must say I am not very pleased with either result. The anti-aliased
| symbols look really ugly. Some black lines have a light-gray line 
| running along them, which would have looked much better if it was 
| background color.

I really don't see what you are describing. They look fine to me.

| I think the true-type-font rendering is much more suitable for scaling 
| pictures with sharp high-contrast edges and narrow lines, such as we are | dealing with here.

| I guess it would not be very difficult to create your Shogi pieces
| through font-based rendering.

For now, these are moot points, because I don't have a font editor.

Muller, why don't you make use of the immensely strong and cunning Gambit
Fruit, written in C, convert it to Forth using c2forth?
http://www.superchessengine.com/gambit_fruit.htm
/Mats

M.Winther:
| Muller, why don't you make use of the immensely strong and cunning 
| Gambit Fruit, written in C, convert it to Forth using c2forth?

Because it does not play any variants, for one. Strong Chess engines
(including my own stronger engine, Joker) normally achieve their superior
performance by exploiting all kind of knowledge on special properties of
the FIDE army (like maximum number of different pieces, the fact that all
leapers except King are automaticaly Knights, and that you have only one
King, that pins can only occur on ortogonals and diagonals, and that in
such a case you can always move along the pin line). And of course a large
part of their strength derives from a lot of strategic knowledge on the
orthodox pieces, (e.g well-tuned Piece-Square Tables) which would be
totally lacking on any fairy pieces you would introduce (even if this was
technically possible). This would stongly bias any strength comparison in
favor of the orthodox pieces, while removing the knowledge (if you cold
locate it, and remove it without doing any unintended fatal damage in a
program that you don't know because it is not your own) is very likely to
destroy the brilliance of the program and reduce it to a mediocre level
that you could have achieved with a fraction of the effort had you written
your own engine from scratch.

I don't understand where this Forth mania comes from. So you can convert
Fruit to Forth, and are left with an approximately 3 times slower Fruit
that is about 120 Elo weaker than the original one. Now what? The fact
that it is written in the same language as the Axiom engine does not mean
it can do anything what the Axiom engine does. The message is not in the
lanuage, it is in what you say.

I have made a 5x blow up of the original gif file with MS Paint,
and indicated with some red arrows what I dislike.

Muller, no, it's not written in the same language as Axiom. Axiom is not
an engine. It is a language, close to Forth, which is used for writing
engines for Zillions. The latest example of an advanced Axiom program is
Grim Reaper, where they have used neural network to conclude which engine
design is the strongest: http://tinyurl.com/578aql

Moreover, advanced chess engines foremostly draw their strength from
advanced algoritm techniques, and certainly not only well-tuned
piece-values. Anyway, I only tried to give you some interesting ideas.
Axiom is a clever thing.
/Mats

| Muller, no, it's not written in the same language as Axiom. Axiom 
| is not an engine. It is a language, close to Forth, which is used 
| for writing engines for Zillions. 

From the way I understand the Axiom description, this is not correct.
Axiom is a general-purpose game-tree-search engine that uses the interface
and protocol specifications of ZoG, and can thus be used as a plug-in for
the ZoG GUI. Axiom can be customized for a specific game through a
powerful scripting language ressembling Forth. But the script in no way
describes an independent engine capable of playing the game being
described. It merely serves to inform the Axiom engine (a binary
executable in DLL form) of the peculiarities of this game (the rules for
making moves and the goal, with perhaps some strategic clues like piece
values). Just like ZoG contains an intrinsic AI that can be configured
through ZRF files with a lisp-like language, and Fairy-Max can be
configured through game descriptions that are lists of step-vectors for
the participating pieces in the fmax.ini file.

The Axiom language is only powerful because it includes primitives that
activate the power of the engine in the DLL.

| Moreover, advanced chess engines foremostly draw their strength 
| from advanced algoritm techniques, and certainly not only well-tuned
| piece-values. 

Sure, you got to have both. Buth the algorithmic techniques are well
known, and comparativey easy to program. Using all search tecniques that
are publicly known, together with  simple but not too rudimentary
evaluation, brings you at about 2400 Elo. (On the CCRL scale, where Rybka
~3000 and Fairy-Max ~ 2000). The remaining strengt must come from
selective pruning of moves that seem poor, or superior strategic insight
that cannot realistically be replaced by extra search depth, and both
requires expert knowledge of the game being played.

| Anyway, I only tried to give you some interesting ideas. Axiom is a 
| clever thing.

Ideas are always welcome, but this one simply 'doesn't fly'. Axiom is
clever, in particular because of its generality. That doesn't mean,
however, that it would automatically any game you give it a script for
very well. Its author stated that Axiom was mainly meant for connection
games like Go, and that for simple Chess-like games the ZoG intrinsic AI
might actually play stronger. But in both cases it will depend strongly
how wel the script that defines the game is written. And I can easily
imagine that you run into a barrier there much earlier in the ZRF language
tan in the Axiom language. But that in itself does not imply that it would
be easier to write a strong Axiom script.

It seems that the Axiom engine nowadays also has an accompanying free GUI,
btw, so it can be used indepedently of ZoG. Greg Schmidt (the Axiom author)
pointed out to me, however, that ZoG does not have as good an engine-GUI
separation as I thought. It can use plug-in engines, but for almost none
of the games there exist ZRF files for it actually does so. These games
are all handled by the AI that is intrinsic and inseparable from the GUI.
So it is not possible to play 99%+ of all ZoG games in any other way than
through the ZoG GUI. Which is then only capable of playing them against a
Human (or Human-operated computer) opponent. 

That makes ZoG quite useless as an entity to communicate with. It simply
has nothing to say...

Muller, of course, it's not strong in the chess-like type of game. But in the future the Axiom engine could develop in the direction of chess variants, and not only connection games, etc. If it's going to happen, then somebody must do it. 
'And so, my fellow chessplayers: ask not what your chess community can do
for you—ask what you can do for your chess community.'
/Mats

A general game engine like Axiom or ZoG will never be as strong as a good
engine dedicated to a single game, or an engine tuned to a much smaller 
homogeneous group of games. You always lose some performance in generalizing.
Fairy-Max is slower than micro-Max in normal Chess, because it has to test
all kind of conditions on the move descriptors (such as 'is this piece a
hopper?', 'can it wrap around the board?', 'is it multi-path?') which
in normal Chess is a total waste of time, as the conditions never occur
there.

So I don't think you have to look in the direction of Axiom for strong
Chess programs. Systems like Axiom are designed for ease of implementing
something completely new at a low but acceptable level very quickly.
Strong programs for Chess variants are easier to derive from existing
strong Chess programs, such as I did with Joker80, which is the Capablanca
Chess version of my normal Chess engine Joker.

Such engines can already play under ZoG, as they use WinBoard protocol,
and a ZoG plug-in adapter for WinBoard does already exist. (I am not sure
if it handles the variants, but this iwould be a problem of the adapter,
which should be fixed there.) The problem is that it is a bit pointless to
play them under ZoG, as you could do nothing that you could not already do
their under WinBoard. On the contrary: under WinBoard such engines can lay
each other, under ZoG they cannot. The new Axiom GUI would be better in
that respect, but I haven't seen it, so I don't know how it would match
up graphically.

Muller, you have implemented the infamous G****c Chess, a Capablanca
variant. I don't know, but it could be a breach of patent. At least it's
a copyright breach. I advise you to remove it. I simply changed positions of the two super-knights, and called it Teutonic Chess instead. The point is that, in Zillions, one can play G****c Chess if one right-clicks and changes the pieces back. This is a variant that you could use instead.
/Mats

Muller, good to hear that you belong to the people that respect
intellectual property. A person from Bulgaria stole my implementation and
my description, including mages, of Bolyar Chess, and presented it as his
creation. He has even exchanged my name with his in the program's
readme-file, claiming that he is the programmer. Remarkable! To my relief
Variant Chess magazine has concluded that Bolyar Chess is probably not
authentic, so it's no great loss.
/Mats

Mr. Winther, I am sorry to hear the news about you getting ripped off.  One
of the missions I see IAGO taking on is making sure the right designers are
credited for their designs and compensated.  I will be looking, as things
grow, to have a legal staff on retainer, to be able to make sure stuff
like this doesn't happen.

I don't like patents. I also don't care if you call my chess variant game
as your own (or anonymous); I am OK with that.