Audio Go Lessons Plug

Fernando Aguilar was so kind to make a sample Audio Go Lesson for Moyo Go.

Ladies - don't you just love that Spanish accent?

I am honored that he - someone who has wiped the floor with more than one 9p - took the time to do it, and perhaps he'll make a full-fledged lesson soon, for the users of Moyo Go Studio.

There is a growing market for Audio Go lessons, and there are more and more people using Moyo Go Studio. Those hundreds who've bought the program are obviously serious in improving at Go (otherwise, why pay sixty dollars for a Go information system, right?).

If there is interest for making Audio Go lessons with Moyo Go Studio, I will make a free SGF viewer available that can play those lessons.

Getting Rid Of The Chinese

Moyo Go has by far the biggest game collection but too many games had Chinese names & rank. And even though someone gave me a transliteration list, not too many names got translated. Today I discovered why. The names have stuff behind them, like how old the player was or which country he or she played for. And often the rank.

Naive sod as I am, always believing in the good of humanity, I simply did a literal search and if there was no exact match, I didn't translate a thing. So not much got translated. But a few hours ago I got off my lazy ass, figured out what all that extra crap meant and wrote some code that gets rid of it and converts it into standard SGF rank properties. One of the funny things I discovered that there's no such thing as a 1p rank, it's called "beginning stage" or something.

Tonight I'll start reading in all pro games again. I have two hundred thousand pro game files from many sources. Heaven permitting, after it has all been done, I will have the most complete, Romanized pro game collection. The code that is able to deal with all violations of the SGF standard is humongous.

Publishing Proof-Of-Concept

Okay, so y'all thought I was losing myself in the avalanche of bugfixes!

Nope - there is something very major (still secret, due to the fact that my enemies will try to prevent it) coming up, and Moyo Go has to be as "clean" as possible for that event.

I finally got around to the Publishing (printing etc.) and I have a proof-of-concept:

xxx.rtf
xxx.pdf
xxx.htm

This is three times the same test output, but all I had to do was click another option. And there is more where that came from :-) As a first test, I'm very happy with it. It all looks like it should look, also on the printer. And this is using a very low quality output setting with only 4::1 antialiasing instead of 16::1.

The first version of publishing will only have one kind of diagrams: Column aligned ones. Will look very cool though. And you'll be able to plaster the same thing as normally comes out of the printer onto your website too! In three-columned pages, for example. I'll try to get this out the door ASAP.

"Drops" Download (Skin)

I have often used this image to show off Moyo Go's skinning capability, but now I realize that this skin never made it into the distribution! It can be downloaded here (Right-click and Save Link Target As).

Save it in C:\Program Files\Moyo Go Studio\Skins and it will become available as a board skin.

I would like to say something about the issue of ripping off a program's resources, like StoneBase did with my board texture, stones and Blake Habers' studio recorded stone sounds. I remember it took me an entire working day to make my board texture bitmap! It starts with finding the perfect texture. I ended up on wood websites looking for large, high-resolution images in non-compressed format. Those are extremely rare. Then I had to make sure the lines/cm and the hue were "just right", so I browsed the web for board samples of expensive Kaya gobans and others. I stretched/compressed the image and changed the RGB distribution to make it look like a nice golden Kaya.

But that was not all of it. I wanted to have the ability to use a small version for a board by using "tiling", but without apparent "seams". That is only possible when you do a trick: You have to flip & mirror the image three times so you get four images, put them together to form one large image, and then the left side merges seamlessly with the right side, and the top with the bottom.

Then I had to compress it just well. At the largest magnification, you should not see JPG artifacts, but neither should it be too large because it takes too long to load otherwise.

Finally, I encrypted the image and added it as a resource. A day of work. It was ripped not by decryption cracking, but by simply turning off board lines, hoshi points and indices, and copying the empty board at full screen size. Same with the encrypted sounds: They were played and recorded with a small utility that can record sounds that are played by "hooking" itself into the data that goes to the sound card. The stones (I draw them using OpenGL) were ripped by making screen captures of them. That became possible because they also stole the board itself, so the stones would blend in perfectly with the board, otherwise there would be an edge between the antialiased stone border and a board of different hue.

So indeed, the Go software world is dog-eat-dog. I wonder where that term came from ;-)

Go Game Assistant Baloney

"Baloney" is US slang for "nonsense".

Go Game Assistant claims to have 56,000 pro games.

Baloney.

20,000 are duplicates!

I do not suspect malice, however. I know for a fact that there is a large pro collection out there in the public domain that has all its games flipped (mirrored). They obviously read that collection and did not have safeguards in place to normalize their Dyer signature or Zobrist hash.

But this is no excuse to keep on advertizing the product with so many games.

I do not want to bitch and moan too much about the Chinese (they have nukes, after all), but I see a pattern here. This is the second time Chinese software does very questionable things. Last week I found StoneBase having ripped my stones (and sounds, and board, and the nicest glyphs), now I find Go Game Assistant well.. grossly "misrepresenting" their number of pro games so that they (what a coincidence) end up just a little above Moyo Go Studio. Sorry to break it to 'ya, guys - you aren't even close.

Update: Someone emailed me to inform me that there is no Chinese conspiracy against me. So they brainwashed him as well ;-)

Antialiased Diagrams

The new diagramming code is done. It looks much better on small diagrams!

This is a 16 pixels - to - 1 antialiased image. Will look great on the web as well (Moyo Go will have "publish to HTML").

Without this sophisticated scaling method, it would have been impossible to read the stone numbers above 99. Ordinary font rendering technology in Windows (or Mac, Linux) is unable to produce such quality on such a small scale.

These neat little Go diagrams look "simple" at first sight, but when you examine closely, you'll see that no other Go software has it.

Because producing such an image is far from trivial. As I said, it is impossible to achieve with state-of-the-art TrueType font rendering technology. It requires all the tricks in the hacking book. I make a Windows API call to make sure font smoothing is enabled. Binary search to quickly determine the best fitting font size for each stone number. Highly optimized pointer arithmetic for the antialiasing code. Palette-handling stuff to be able to work with 8-bit grayscale bitmaps, because antialiasing is faster on less data. And a handful of heuristics to make the stones look good at all scales. Omit any of these tricks and the image looks either sub-optimal or takes too long to render. Don't forget that a 16::1 antialiased image of 300 x 300 pixels requires a bitmap of 1200 x 1200 pixels, and that the user expects to browse through found games at several per second. So you have to average 4 pixel intensities into one, and do that 1200 x 1200 = 1.5 million times, in a split second. Amongst several other time-consuming things, like doing it again, but 4::1, and converting the resulting 8 bit image to 24 bit, to be able to draw in color on top of it.

And it goes on and on. There are several more, highly technical "issues" with this that can literally crash a user's computer or make the image look terrible on other computers. I do not want to go into details, but I can tell you that it has to do with the graphic card hardware & driver, and with an error in Microsofts documentation of the Font Smoothing API. Apart from that, I discovered something very major and totally undocumented about font smoothing, and if that discovery is not made, it will also not work properly on all machines.

I am not trying to be boastful - it was pretty easy for me, someone who has mainly worked in the image analysis/manipulation/creation field. I just wanted to explain, it might be interesting to know how much effort and engineering goes into seemingly trivial things. At least in Moyo Go :-)

Not Invented Here

I'm working on the page rendering engine.
There are two parts - the positioning logic and the rendering code.

This is about the diagram rendering code.
It's impractical to use the Go font I purchased, called "Tokyo".
Several reasons.

One is that the Report Generator can't handle the font - each Go stone is represented by up to four characters - breaking the rendering code that assumes the rendering string has as much characters as its length. I could augment this - I have the source - but there are more impediments to using a font-based diagram rendering solution.

Another one is that although the font prints OK from PDF, a PDF reader is not able to display it perfectly, due to the fact that the font uses a clever trick to build a glyph out of a handful of characters.

Last but not least, I am not allowed, or even physically unable to embed that font into HTML, RTF etc. And I hate having to support two rendering engines.

My only good option is to render a bitmap image of the diagrams. But that is easier said than done, because I do not accept jaggy edges of circles, or coarse stone numbers when using a tiny font.

Fortunately I have made some very fast anti-aliasing code (used some years ago in the Go board), so what I will do is draw the image twice as large as it should be and then antialias it.

A positive side effect of making an antialiasing full-featured diagram rendering engine is that I can improve upon the existing "match" diagram.