[ggo-discussion] Re: glGo 1.2 beta

Thanks for the detailed feedback!

About scorer freezes: I got a couple of reports concerning this. I did 
some changes to the code which appear to get rid of possible crashes and 
freezes. Beta-2 is available for download now. Beta-2 Windows and Linux 
are identical, Mac version is still Beta-1 and a bit outdated, Mac 
Beta-2 is currently compiling as of writing this.


> 1) Open a saved sgf file for viewing with glGo.  (this bug does not occur 
> for observed games)
> 2) Open a notepad window so that it is the active window and on top of the 
> 3d game board pane in glGo.
> 3) Move the mouse from the Notepad window to hover over the 3d Game board
> 4) glGo crashes!

I fixed this yesterday. Forgot if this change went into Windows Beta-2. 
If not, it will be in 1.2 final in any case.


> First, glGo doesn't like being on top of or behind translucent 
> windows.  Applications such as DUMeter and Trillian allow partial 
> transparency of their windows, and when one of those windows overlaps the 
> game board, bizarre artifacts occur.

I don't know a way to fix this. The 3D board embedded into a window is 
quite some ugly hack. Usually OpenGL prefers to run full-screen. That's 
not very useful for a Go client, though. :)
I observed the same issue with other software which runs OpenGL within a 
window. My take is: General OpenGL-on-Windows problem.


> 1) Launch glGo and click the 'load a game' button
> 2) Do not load a game from the load SGF file dialog.  Keep the dialog open.
> 3) Open a game through another means, such as double-clicking an SGF file 
> in windows explorer, or launching a shortcut.
> 4) The game board doesn't draw.  Close the 'load SGF' dialog, and the board 
> will draw with limited graphics (b/w, no textures, etc).

Geez... This is nasty. The File-Open dialog is a modal dialog, so it 
will freeze the rest of the application as long it's open. I cannot 
change this as this is the Windows native File-Open dialog.
When you use the "Load Game" button, the File-Open dialog comes before 
the 3D stuff is initialized. So if you load *another* game, the 3D 
textures wern't loaded yet and you get a half-initialized display.
Doing above with 2D board crashes glGo.
Not sure if this is easily fixable. Certainly fixable, but don't know 
how much work that involves. Each 3D and 2D boards use shared resources. 
This causes the mentioned problem when one board didn't init all 
resources, but the second board thinks the resources are available 
because it's the second board - in that case they *usually* are 
available already as the first board loaded them. This might sound 
silly, but saves a lot of memory because you only need to store all the 
textures and images once in RAM and share them among multiple boards. I 
spent quite some efforts to save memory here and I'm not sure if I want 
to sacrifice memory savings for making it more fool-proof.
So, just don't do it. :*)


Peter

Other related posts: