Friday, June 27, 2008

New ANTLR targets

Till now I used javacc (http://javacc.dev.java.net/), the Java Compiler Compiler, for creating my parsers.

Like I said earlier (http://shogi-software.blogspot.com/2008/01/tsume-shogi-parser-or-how-to-store-28k.html) I was hoping to try ANTLR out.

Today I read two interesting pieces of information:
  1. There is an IDE to develop and debug grammars, ANTLRWorks.
  2. New (3.1) ANTLR would support JavaScript and ActionScript as targets (platforms in which parsers generated by ANTLR can run).
It is certainly big motivation for me to check this tool out. First of all, ANTLRWorks will make designing and testing my Shogi grammars much easier and faster.
Secondly, new targets will allow creation of shogi games browsing/viewing software on these two very popular platforms: JavaScript and Flash/Flex.

I am going to give it a try very soon.

Tuesday, June 24, 2008

Visiting the Dark Side

I've been inactive (as a blogger) for quite a time now.

Due to some technical problems MyJavaServer.com didn't accept any new files. That made me search for alternative hosting site for my experiments.
I couldn't find anything similar to mjs but I googled http://www.vndv.com/ out. They give you free hosting for your PHP pages, MySQL databases, subdomains, ftp access, no advertisements, very decent user interface, tutorials. But no Java... Well, nobody's perfect :-)
I spent time on toying a little bit with PHP and client side technologies.

I'll show you my firs PHP page (http://fatboldcyclop.vndv.com/index.php):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>PHP Test</title>
</head>
<body>
  <?php phpinfo(); ?>
</body>
</html>

I am very proud of it :-). But seriously, I did some reading on PHP and I found it interesting. I decided to check it out later and take a closer look at client side web development with JavaScript and CSS first.
My first attempt was to write JavaScript Shogi Board Viewer. I'll describe the program on this blog later. Now I'll share with you my impressions on JavaScript (JS)-- it was basically my first real contact with the language.

First of all, I greatly underestimated the language. Now I think that it is a flexible, dynamic and powerful language. You can do many thing using small clever JS "tricks", but...

But developing in JS is for me a road trip through hell. I managed to get used to auto complete feature of Java IDEs. In Java, which is very strict, the tool can "easily" predict what the programmer can type (object properties and methods, etc.). With JavaScript it's not so easy -- it is dynamic, method and properties can be added on the fly, etc. But IDE is only small part of the problem.
The biggest pain was for me browser compatibility. I had a piece of code ruining smoothly on few browsers (i.e. FireFox 2 and 3, Opera, Safari) but IE somehow didn't like a line or two. Figuring out which line was the real challenge.

Debugging JS is so difficult. Thank God for FireBug. It saved me a lot of time and nerves, but it comes only with FireFox. Fortunately, Opera (9.5) and IE 8.0beta also have a "cheaper" version of the tool.

Another annoying thing about client side web development is CSS compliance. I tried to do simple things like having 2 text boxes next to each other. O what fun it is to make it work exactly the same in all the browsers. This one gives you an extra margin between two boxes, other resizes one box, etc. etc.
By the way, I fought with IE7.0 for correct placement of pieces on the board in my SFEN converter. I won the battle but I lost the war. After I finally forced IE7 to show it right, IE8 was released. And of course, the newer version of the browser has it's own way of positioning page elements.

Anyway, I'm glad I gave it a try. I learnt few things:
  • I lack the imagination to think how people did it before the FireFox came to life.
  • browsershots.org is a great tool to test your web design in different browsers.
  • Trying/learning different languages opens your eyes to new possibilities.
  • JavaScript is an interesting and powerful language but using it is not such fun at all.
  • If you want to show HTML code on your blog, you could use this tool to make it possible.
All in all it was a very educational experiment for me -- short walk on the dark side of the web development.

Monday, June 23, 2008

Unicode for Shogi characters


To be able to translate Shogi data between formats you have to know possible piece symbols. I collected  the information I could get (mainly from wikipedia.org) in the following table. Then I found (on http://www.rikai.com/library/kanjitables/kanji_codes.unicode.shtml) unicode values for eaech Shogi piece.
Shogi pieces



















































































































































































English name


Unicode

for abbr. Kanji


Kanji


Rōmaji


Meaning


Abbreviations


Symbol


Kanji


Rōmaji


King (reigning)


738B


王将


ōshō


royal general


K





ō


King (challenging)


7389


玉将


gyokushō


jeweled general


K





gyoku


Rook


98DB


飛車


hisha


flying chariot


R





hi


Promoted rook (Dragon)


9F8D or 7ADC


龍王


ryūō


dragon king


+R


龍 or



ryū


Bishop


89D2


角行


kakugyō


angle mover


B





kaku


Promoted bishop (Horse)


99AC


龍馬


ryūma or ryūme


dragon horse


+B





uma


Gold general (Gold)


91D1


金将


kinshō


gold general


G





kin


Silver general (Silver)


9280


銀将


ginshō


silver general


S





gin


Promoted silver


5168


成銀


narigin


promoted silver


+S








Knight


6842


桂馬


keima


horse


N





kei


Promoted knight


572D or 4ECA


成桂


narikei


promoted laurel


+N


(圭 or
今)





Lance


9999


香車


kyōsha


incense chariot


L





kyō


Promoted lance


674F or 4EDD


成香


narikyō


promoted incense


+L


(杏 or
仝)





Pawn


6B69


歩兵


fuhyō


foot soldier


p





fu


Promoted pawn (tokin)


3068 or 4E2A


と金


tokin


reaches gold


+p


と (or
个)


to


Coordinates
In KIF files the characters are Shift-JIS encoded. Characters used to describe shogi board coordinates and their unicode values are listed below.





































































































description


char


unicode


1st column





FF11


2nd column





FF12


3rd column





FF13


4th column





FF14


5th column





FF15


6th column





FF16


7th column





FF17


8th column





FF18


9th column





FF19


1st row





4E00


2nd row





4E8C


3rd row





4E09


4th row





56DB


5th row





4E94


6th row





516D


7th row





4E03


8th row





516B


9th row





4E5D




Move modificators
The symbols used in Kifu to identify the piece to move (when there is
a situation in which more then one piece of the same kind can reach
given destination):




































































symbol

unicode

meaning


76F4

move straight


5F15

pull (back)


4E0A

go forward (literally means “up”)


5BC4

go to the side


53F3

right


5dE6

left

右引





right-back

右寄





right-go to the side

右上





right up

左引





left-back

左寄





left-go to the side

左上





left up


I hope someone finds this information useful.

Thursday, March 27, 2008

Requirements for new Shogi game format

There seems to be great need for a single computer standard for exchanging Shogi games data.

There has been ongoing debate on discussion board (shogi-l) for years now.

Although the discussion tends to be difficult (like the never ending dillema "which came first, the chicken or the egg") but the point is quite simple. After scanning the post you notice that there are just a few simple requirements to be fulfilled.

I try to collect them here. The standard should let for the following features:
  1. Storing multiple games in one file.
  2. Providing game information (type of the game, players, date, event, outcome, ...) in the way that any shogi software could correctly interpret it.
  3. Allowing to store variants.
  4. Allowing to store comments in different languages.
  5. Allowing to embed multimedia contents (board markups, pictures, sounds, movies) in the comments.
Except for the last (embedding multimedia) I consider them to be the core features. They have to be included into the specification. In my opinion no matter if the standard is totally new or if it's based on some existing format (Simple Game Format, Portable Shogi Notation, KIF) it needs to address the problems mentioned above.

By the way, they seem to be easy to implement:

Ad 1) If the single game has concise and well defined description, the games are easily distinguishable/separable. Even if it is not the case, some game separator could be introduced.

Ad 2) The information could be provided in key/value pairs (let's not bother about their form now), for example sente:Sato Yasumitsu or [sente "Sato Yasumitsu"].

We would have to agree on the standard set of tags (sente, gote, event, etc.). The less, the better. The standard, to be flexible and extensible, would state that other tags are allowed but are not given any special meaning. This way if one program needs to add some information that matters only to it, it uses his own tag without any side effects on other programs.

Ad 3) There are many possibilities here. SGF and PSN uses tree-like text data structure for example. I could think of few more solutions but the actual implementation doesn't really matter. Ideally, the structure should be easy for the machines to decode but still easy enough for humans to read it.

Ad 4) For comments we should opt for standard Unicode encoding like UTF-8.

Ad 5) I have some reservations about number 5. It will greatly improve viewing the games with software but it also will make the format less readable by humans.

The most important thing is to make the multimedia comments/markups optional. I imagine not every Shogi game viewer will want the feature (furthermore I believe some target devices, like simple cell-phones, won't be able to use it).

I would split the problem of multimedia comments into two categories:
  1. markups that don't require embedding additional data (markups for actions that are understand by viewer: drawing arrows, coloring board fields, showing hyper link, etc.)
  2. markups that require embedding additional data (pictures, sounds, movies, etc.)
The first category is easy. The more I think about the second category the less I am convinced it belongs to the standard ;-)

And what do you think?

Tuesday, February 12, 2008

Tsumeshogi diagrams with Kanji, part III

I finally managed to finish PDF collection of 300 Tsumeshogi problems with pieces represented by Kanji characters (http://shogitools.googlecode.com/files/tsume_collection_0_3.pdf).

Now I am starting to validate the data. It turns out that there are few mistakes in the input data.

Missing tsume
I produced the collection from problems posted weekly on Shogi-l by Reijer Grimbergen.
There was 50 "episodes", 6 problems each which gives 300 problems. I dug the posts from our archives.
I found out that the 35th part of the series was missing from the archives -- or at least I couldn't find it.

Does anyone, by any chance has a copy of the post or the 6 problems?

Errors in definition
The second problem are errors in the definition. Some problems posted on shogi-l have clearly mistaken data:

Problem 103:
Black: S3d, S2c, P1f In hand: B, G
White: K2d, B5a, L1c, L1b, P3d, P2d
diagram

Problem 138:
Black: +B3d, B1d, N1a, L4c In hand: N
White: K2b, N1a, P1c
diagram

Problem 198:
Black: R3a, B4e, S4b In hand: R
White: K2b, G1c, S4b, N2a, L1b, P2e
diagram

Problem 297:
Black: R3f, S1d In hand: G, 2S
White: K3d, +B4b, G2e, L1a, P3b, P1d
diagram

Does somebody have any ideas how the problems should look like?


Mistakes in the problems
There could be some mistakes in the problems themselves. I found the two while browsing the archives (http://www.shogi.net/shogi-l/Archive/1993/Njan27-01.txt, http://www.shogi.net/shogi-l/Archive/1993/Njan27-02.txt). I made required corrections to problems:
12. 7l1/6k2/7p1/6p2/6N2/7+pP/9/9/9 B SGR
44. 9/6p2/5B1g1/5p2R/6k2/9/6S2/9/9 B B


If you find any errors while solving the problems, please drop a note on Shogi-l, or as a comment to this post.

Thanks in advance!

Thursday, February 7, 2008

Tsumeshogi diagrams with Kanji, part II

The delay

As I wrote earlier I had been planning to produce this version of "my" Tsumeshogi Collection for a long time now. The only thing that was putting me off was weird interpretation of "reference-orientation" XSL-FO attribute. The specification describes it as follows:

The reference-orientation property defines the direction for top for the content-rectangle of the reference-area.




Property Values
ValueDescription
0Default. The orientation of this area has the same orientation as the containing reference-area
90The orientation is rotated 90 degrees from the orientation of the containing reference-area
180The orientation is rotated 180 degrees from the orientation of the containing reference-area
270The orientation is rotated 270 degrees from the orientation of the containing reference-area
-90Same as specifying 270
-180Same as specifying 180
-270Same as specifying 90

The first problem was that in Apache FOP using -90, -180 and -270 as reference-orientation instead of 90, 180 and 270 resulted in content being drawn outside its block.

The first results

The commercial equivalent of FOP, RenderX' XEP, did better in this area. I used to produce my first version of the collection with Kanji for the Shogi pieces.

The power of the Open Source community

Although XEP is a decent piece of software (and the company provides free personal edition) I decided to keep on looking for open source alternative.

I described what I am doing and I asked the question about the strange FOP behaviour on public w3.org lists. I didn't have to wait long for the answer. Jeremias Maerki informed me that the situation I described is a known bug in Apache FOP which hasn't been resolved yet.

Bad news, but at least I finally knew what is going on...

The same day, few hours later, Jeremias posted his second answer: he fixed the bug!

After downloading the newest version of FOP from Apache's site I am now able to produce the collection the way I wanted to.

Monday, February 4, 2008

Tsumeshogi diagrams with Kanji

I have just found a PDF (from xsl-fo) renderer which properly handles rotated text in tables.

I produced Tsumeshogi collection with 300 problems using "international" symbols. After that I decided to do the same thing using Kanji characters.

The PDF generator I used, Apache FOP, acted strange when it came to rotated characters (the idea was to use Kanji representation for Shogi diagrams, black pieces heading up, white pieces upside down). So I gave up.

Few days ago I found out, that there is a commercial implementation of PDF renderer (fortunately, they also provied "personal licence") -- RenderX's XEP (http://www.renderx.com/tools/xep.html).

Thank's to this piece of software I will soon be able to produce my Tsumeshogi collection using Kanji characters.

Just give me a day or two...