glGo 0.0.6 ---------- A prototype for 3D Goban as a native Win32 and Linux C++ implementation based on OpenGL, SDL and wxWindows. Table of Content (A) Requirements (B) Usage (C) GNU Go / GTP (D) Saving the configuration (E) Known problems (F) How to use own images and sounds (G) Technical informations (H) Compilation (I) The Python Playermanager (J) Copyright (A) REQUIREMENTS ------------------------------------------------------------------------------- ! If you use the OpenGL board you will not have much fun without a proper 3D hardware driver ! ------------------------------------------------------------------------------- The goban display is available in two modes: 3D based on OpenGL and 2D based on SDL. The SDL 2D board is pretty much looking the same as the gGo/Java board. Some users might not have a graphic card with OpenGL support (but those must be very old, any consumer card sold after 1998 supports OpenGL) or prefer the classic 2D view, so the 2D mode might be an alternative. The default is the 2D board (since version 0.0.5.4) as obviously a lot of people have trouble with their OpenGL drivers and are unable to find the documentation explaining the existance of an additional 2D board. You can switch between 3D and 2D board display in the preferences dialog. If you have a proper 3D graphiccard, make sure you have some recent driver from your hardware manufactorer installed. The default drivers that come with Windows do *NOT* work well. The most common consumer cards should be from NVidia or ATI, all of them will work properly with glGo if you have a NVIdia or ATI driver installed. Be careful with NVidia, there will be two drivers available for "NVidia Riva TNT" card in the Windows driver selection: One from Microsoft and one from NVidia. Use the NVidia one, the Microsoft driver is useless. If you run Linux and don't have a hardware driver installed, the Mesa libraries might work, but will be inferior to a real driver. There are both NVidia and ATI drivers for Linux available (my old NVidia TNT 1 card works fine with the latest NVidia/Linux driver). The OpenGL mode won't work well without a hardware driver installed. It will be slow and ugly. I am aware this is a serious limitation to the program. Most gamers have those drivers up to date, but the average IGS user is no computer gamer and certainly will have the default Microsoft Windows drivers installed, which won't work with glGo. The glGo sound system is based on the OpenAL or SDL mixer libraries. Both are available and can be selected from the preferences dialog. OpenAL is the default system and basically superior. Both OpenAL and SDL_mixer runtime support are provided with the glGo Windows installer. On Linux you need to install OpenAL and/or SDL mixer from your distribution, it is not included in the glGo installer. There is a small "soundtest" program which will play three sounds to test if OpenAL works on your system. Start it from a commandline (DOS console or xterm) and try "soundtest 0" to start the OpenAL test and "soundtest 1" for the SDL mixer test. The SDL board requires the SDL, SDL_image, SDL_ttf and SDL_gfx libraries. They are all included in the Windows installer, on Windows you don't need anything additional. On Linux you require libsdl, libsdl_ttf and libsdl_image, which skip with all major Linux distributions. It does not make sense to include the SDL runtime libraries on Linux as they are all available with your distribution already. There is "sdltest" program which will open the SDL board only using the SDL libraries. If this works, it should work within glGo, too. Hit the Space key to toggle through 19x19, 13x13 and 9x9 boards, 'c' to toggle coordinates, 'f' to toggle fixed and scaled fonts. glGo requires the Python 2.3 runtime library which is included in the Windows installer. Linux users please install Python from their distribution. For installation information please refer to the file INSTALL or Install.txt. (B) USAGE Start glGo on Windows either using the desktop or the startmenu icon. On Linux type "glGo" in a shell. There are currently two different board displays available: The 3D board based on OpenGL and a 2D board based on SDL. To switch between both types use the "Board type" selection in the preferences dialog. All newly opened boards will use this set type (the current board won't change if you access the dialog from a board window). You find several switches for the OpenGL display in the "OpenGL Options" dialogs from the "View" menu. If glGo runs too slow you can try tinkering these options. The manual contains some detailed information what each option does. There is some extensive keyboard control. Please see the provided manual for details. In short, use the cursor keys plus Control, Shift or Alt to rotate and shift the board. Numpad plus/minus zooms in and out. Backspace resets the default view. Cursor right/left without modifier key will move forward/backward. There are more keys, see the manual. Some hints and informations about the OpenGL settings can be found in the manual. Please have a look. The IGS client is slowly making progress and getting similar to the gGo Java interface. Observing and playing own games is implemented. Not yet supported is scoring games. This is *NOT* a finished and usable application. Comments and suggestions are welcome. Please drop me an email. (C) GNU Go / GTP Mode You can play with GNU Go. As of glGo version 0.0.4.3 GNU Go is bundled into the Windows installer. If you are on Linux, you need to download it seperately or install it from your distribution. As the gnugo.exe file is in the same folder as the glGo executable, glGo won't have trouble finding the file. If it does, it will complain and offer the user a way to find the right file. There is a problem on Linux: If gnugo is not found, glGo crashes. The problem is, when wxWindows tries to execute a command which does not exist, it will start a real process and return a PID. The process will quit again after few seconds, but meanwhile glGo bailed out. I need to fix this. If gnugo is found, things work fine. To start a game with GNU Go, select menu GTP - Connect GTP, and you can configure the game options. To end a GNU Go game and return to normal playing mode, you need to close the GTP connection, select menu GTP - Close GTP. There is a GTP console available to see and manually control the GTP transfer, as known from gGo/Java already. Resuming games is supported. Usage is quite the same as in gGo/Java. Not supported yet are clocks and scoring. Hint: Type "estimate_score" in the GTP console after passing to see the score. Basically playing GNU Go should work. With release 0.0.4.7 you can use GNU Go to estimate the score of a game. You can call this using the "GTP-Guess score" menuitem in a board window. The estimation will be run on a temporay SGF file using the current move. (D) SAVING THE CONFIGUTATION The configuration is saved into a plain text file. On Linux in $HOME/.glGo/glGo.rc and on Windows into $HOME/glGo/glGo.rc, where $HOME usually resolves into something like: C:\Documents and Settings\. This is at least the case for Windows 2000 and XP, older Windows versions might handle this different. Windows 9x does not know about $HOME. In versions previous to 0.0.5 the Windows settings were written into the registry. However, after some thinking and user feedback I decided to drop this and use a simple textfile instead. This way it is much more convinient to make a backup of the configuration by simply copying the file somewhere safe. (E) KNOWN PROBLEMS Generally expect this application to be unstable. This is not a finished application and in no way stable software. If it crashes, don't panic. Please try to reproduce the problem and report the bug to me either by email or post it in the forums at the sourceforge project page. On IGS only 19x19 games are supported. Any other size currently simply won't work. This is on my TODO list for one of the next releases. When opening a board on Windows, sometimes there are display artifacts. Once the window got a bit resized or moved, the artifacts are gone. Another good idea is to enable "Autohide starter" in the preferences, this seems to solve the issue as well. This does not happen on Linux. I don't know the reason for this. There is a big problem on Linux when the GNU Go binary cannot be found. Unlike Windows, where a nice wizard appears telling the user what to do, glGo on Linux will just crash. I am currently trying to solve this problem. When using glGo on Linux, make sure the GNU Go binary is somewhere in your path environment. If you run a GNU Go score estimation and kill the gnugo process via task manager or killall, glGo will crash. The SGF parser has trouble with Kogos Joseki dictionary. I remember this problem from gGo/Java, Kogo has some wired variations and is not SGF conform. This is on my TODO list. When reading an english komi value (like 6.5) with a german locale, the komi will be detected as invalid (it wants 6,5). I did not find a solution for this yet. Switch to english if you are german and this bothers you, otherwise just ignore it. The captures algorithm has trouble with Kos. When loading SGF files this could produce some wired results. With observed IGS games it should be ok as then glGo won't calculate captures itself but instead use the provided list sent from IGS. On Linux, toggling the toolbar creates some artifacts; resize the window manually a little to fix this. I don't know why this happens, it's ok on Windows. The fonts are not yet optimal, the underlaying grid disturbs the display. This is on my TODO list. The new OpenGL scissor test causes problems with the cursor ghost stone in own games. Automatch does not display a dialog yet. On TODO list. The localhost server mechanism on Windows is a potential security risk if you run Windows without firewall. However, if you do such, you have much more serious things to worry about than someone hacking your Go client. The new UGF parser (new as of 0.0.6) is not much tested. Please give it a good beating and send me those files it couldn't load. I simply don't have many UGF files myself (Anyone has except PandaNet magazine subscribers?) If you encounter trouble, please don't hesitate to tell me about it. What I don't know I cannot solve. (F) HOW TO USE OWN IMAGES AND SOUNDS You find the sounds in the share directory within the glGo installation. On Linux this is /opt/glGo/share, on Windows C:\Program Files\glGo\share (or whereever you installed glGo). In this directory you find the sound files and a file data.dat which contains the default images to get rid of the cluttered share directory. Using own sound files is pretty easy, just replace the existing sound files with your own. You need to use exactly the filenames. To replace the stone sound, you need to replace "stone.ogg", etc. The current sounds were taken from CGoban2 with the permission of the author. If you have a cool sound, please send it to me if you want to share it! To use own images, you need to create a directory data/ within the share directory and drop the images there. glGo will first search real existing files, and if they are not found use the defaults in data.dat. The images must have a certain name, format and size: The goban kaya background : kaya.jpg 512x512 The 3D white stone texture: white_tex.jpg 64x64 The white last-move marker: mark_white.jpg 64x64 The black last-move marker: mark_black.jpg 64x64 The SDL white stones : hyuga1.png - hyuga8.png 49x49 The SDL black stone : blk.png 49x49 The SDL table background : table.jpg 100x100 Example: To replace the kaya goban background, copy an image file kaya.jpg of size 512x512 pixels into the following location: Windows: C:\Program Files\glGo\share\data\kaya.jpg Linux: /opt/glGo/share/data/kaya.jpg If you use another image format or another size, it might work or not. Probably not. The OpenGL images *must* have a size of a power of two (SDL doesn't care). You can also use an own font file for OpenGL board coordinates and text markers by replacing the coords_font.txf file in the share directory. If you want to create those font files yourself, have a look at the gentexfont program within the GLUT distribution which allows to convert a X-server font to a .txf file. I have no idea if there is a way to create these font files on Windows. You can find them on the net, the PLIB example code has a couple of those font files. The font file used for the SDL 2D board is FreeSerif.ttf. You can replace this with another truetype font file if you wish to change the 2D font. (G) TECHNICAL INFORMATIONS I write glGo on my old computer, a Pentium 2 333 MHz with a Diamond Viper (Riva TNT1) graphiccard. This is a very low end system, but at least has the advantage that if glGo runs on my computer, it will run on all computers. :) The used OpenGL version is 1.4, but is compatible with OpenGL 1.1, which is what Microsoft ships with Windows (I take this as a hint Microsoft wants developers not to use OpenGL but DirectX). The used wxWindows version is 2.4.2 The used SDL version is 1.2.6 The Linux binary is compiled with GCC 3.3.2, the Windows binary with MinGW (GCC 3.2). (H) COMPILATION To compile glGo you require a couple of libraries and the headers: * wxWindows 2.4 configure has an option --enable-static-wx to link statically against wxWindows, but if you compile for your own system, you probably should do a dynamic link. Additionally you need wxGTK-GL and wxGTK-XRC. Both are included in the package libwxgtk2.4-contrib on Debian. It might be similar on other distributions. * GTK+ 1.2 * SDL 1.2 * SDL_mixer 1.2 * SDL_image 1.2 * SDL_ttf 2.0 * SDL_gfx 2.0.8 * PLIB 1.6.0 * ZZiplib * Python 2.3 * OpenGL (including the glext.h header file, get it from www.opengl.org) * OpenAL (optional, you can use --disable-openal in configure) * Ogg, Vorbis, Vorbisfile on Windows (these are already included in OpenAL/Linux) Most of these libraries should be included in your Linux distribution. The configure script should check all these requirements except wxGTK-GL and wxGTK-XRC (I need to figure out how to find them reliable). The absence of these two will be noticed in the final link step. If you compile zziplib, you need to pass these flags to the compiler: -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES Otherwise you will get a linker error "unresolved symbol: zzip_init_io64". Check "wx-config --cxxflags" if the output shows the above. Run configure, make, make install The standard install target is /usr/local. It is a good idea not to change this, as glGo won't find the shared data directory otherwise. If you really want to relocate the installation directory, either adjust the sources at the end of the glGo.cpp file where the checked directories are listed, or use the commandline parameter -s or set the "GLGO_SHARED_PATH" environment variable to point to an alternative shared directory. You can build glGo with wxGTK compiled for GTK+-2.0. I tested it with a selfcompiled wxWindows. glGo works well with GTK+-2.0. But it pulled in a heap of unused library dependencies of Gnome libs, something I want to avoid for the Linux binary release. And it does not look significantly better or different. Also wxGTK with GTK+-2.0 is marked as experimental. If you want GTK+-2.0, compile it yourself. The glGo sourcecode does not require any modification for this, just get wxGTK using GTK+-2.0 and link glGo against this. Compiling glGo on a Windows system is somewhat tricky. I use MinGW for the Win32 binary builds using a set of makefiles based on scripts shipping with wxWindows. Those makefiles are available in the CVS. You need to compile the required libraries yourself or get the win32 runtime files which usually come with a MSVC lib. You can convert this lib with the "reimp" tool for use with MinGW. Otherwise you can compile glGo with MSVC, there are project files for Visual Studio 6.0 available in the CVS on sourceforge. If you use MSVC, you might want to get stlport, as the Microsoft STL implementation which ships with MSVC is outdated. The CVS has makefiles for Borlands C++ 5.5 free commandline tools, but they are quite outdated and will require some adjustments. To sum it up, glGo compiles pretty painless on Linux if you have all libraries available, and is a major headache to compile on Windows. It took me some days to get set up with Win32-MinGW, wxWindows and all the SDL libraries. (I) THE PYTHON PLAYERMANAGER With glGo 0.0.5.5 comes a new player database which is implemented in Python and used as a sort of "plugin" (embedded python, to be exact) within glGo. Right now it offers the friends/bozo list known from the Java gGo, the possibility to edit and assign custom flags and write a comments about a player. Additionally directories can be scanned for SGF files and all games of a certain player be looked up in the playermanager. Why as Python plugin, you ask? Such stuff like database access is much easier to do in Python than in C++, and the possibility to access Python code from within a C/C++ program makes integration into glGo painless. The idea of a player database has been around and suggested for the gGo Java development since a year ago, but I never implemented it because it seemed a quite complex task. With Python such things are easier and faster to write. The only disadvantage I can see is, on Linux you need Python 2.3 runtime installed. But Python ships with all Linux distributions, so it should not be a big deal. Type "apt-get install python" or whatever your distribution offers and you are set. Windows users don't need to bother, the glGo Windows installer comes with all required libraries. There are several ways to access and edit the player database. From within glGo you can assign friend or bozo status to a player from a dialog, the playertable popup or the playerinfo dialog - just like in the Java gGo client. I do not plan to add much more to glGo itself. Instead there is a seperate application which will allow to edit and access the database in more detail, which is written in Python. Both glGo and the standalone GUI access the same database, you can edit it with the GUI while running glGo without problem as glGo will automatically detect if the database has been changed. There is also a simple Python commandline interface for the database, which might be useful for the terminal fans out there. The GUI allows you to define customized flags, like "Escaper" or "Cool dude", and then assign these flags to a player both in glGo and the playermanager. Go to "Edit" - "Edit flags" in the playermanager to define up to 5 flags. You will then see checkboxes for each custom flag in the playerinfo dialogs of glGo and Playermanager. Please note a flag is stored as its number (1-5) in a player, so if you for example assign flag #1 as "Escaper" and set flag #1 in a player, then change flag #1 to "Cool dude", all players formerly flagged as "Escaper" are now "Cool dudes". You can use the filter choicebox in the first playermanager tab to get all players with certain flags set listed if you want to do some cleanups. You can write a short comment about each player, this feature can be accessed from both glGo and Playermanager. You can cleanup the player database, which will remove all players which are not friend or bozo, have no flags and no comment set. If you use the autosave feature in glGo (or have a game collection on your disk from whatever source), you can create an index of SGF games within a directory with the "Scan directory" menuitem in the playermanager. The SGF game headers are parsed and the information written in to an index file. When you open the player info dialog in playermanager, you get a list of games with this player. Double-clicking on a table row opens the SGF in glGo if the glGo localserver mechanism is enabled. The "Cleanup games" menuitem will remove all game entries from the index where no SGF file was found. This is useful if you manually deleted SGF files from a previously scanned directory. The SGF index is in no way as sophisticated as Kombilo. The idea is simply to find all games a certain player has played. For more extensive studying I strongly recommand the usage of Kombilo, excellent program. Both the Python GUI and commandline applications are bundled in the glGo installation, see the "pm" directory in the glGo installation directory, but (!) these require Python and wxPython installed (wxPython for the GUI, commandline runs without wxPython). I am aware most users won't have wxPython available. Most Linux users will have Python (you need it anyways to run glGo), but probably not wxPython. Windows users will in most cases have neither. There are standalone installers for both Windows and Linux available for download with the GUI and commandline tools which bundle Python and wxPython. See it as an add-on for glGo. I made it an extra download because it is quite large and I don't want to bloat your system if you might already have the require Python installed, and this way I can release glGo or the database GUI seperately when I change things. The Python scripts which are already included in glGo are small files and exactly the same as the standalone installer, so if you have wxPython installed, use those and you don't need the extra installer. (J) COPYRIGHT Written by Peter Strempel . The artwork was designed by Tweet . Copyright (c) 2003, Peter Strempel This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Please see the file COPYING or Copying.txt within this distribution.