[ggo-discussion] Re: SGF tree display

Steffen Dettmer wrote:

> It's realized in Python? Or are you just prototyping?

Just prototyping. Although both glGo and gGo use a couple of embedded 
Python code (gGo with Jython, glGo does real embedding), I think there 
is no advantage to realize the tree in Python. The display code itself 
is Java and wxWindows specific, so needs to be implemented for each 
platform, and the core code which creates the tree should be easily 
portable to Java or C++, so using Python for this part only somewhat 
makes little sense.

The non-SGF fileparsers and the new friends/bozo/playerdatabase code are 
realized in Python, that's where Python really comes handy. Not so much 
for the GUI stuff.


> I don't think at my Linux fullfills this (locate pygame found
> nothing). Hopefully you'd find a way to make the package
> installable with ease, like gGo which profits of Java standard.

I won't worry much about the prototype demo now, this is just for 
testing. Of course the final implementation of the tree will be 
available on all platforms on which gGo respectivly glGo run.


> Just as a probably stupid idea: Maybe in upcoming versions the 3D
> is a kind of "plugin" for gGo.

There is no real good 3D engine for Java. Java3D sucks (in my opinion) 
and is hell of slow. There is a cool 3D chess board in Java (look at 
Jose project on sourceforge). Its 3D board looks cool, but is absolutely 
unusable on my computer (which is old but such simple 3D things do not 
need a 2 GHz CPU).
There are some OpenGL wrappers for Java (OGL or whatever it was called), 
but those projects look abandoned. Eventually, Sun and SGI announced the 
development of OpenGL integration into Java few months ago, but that 
might will take until end of 2004 or 2005 to be available.

Until then I won't do anything with Java and 3D, as I don't want to use 
Java3D nor some third-party wrapper which has been last updated 2001 or 
something.


 > some "external drawing engine", e.g. some SDL
> application which is a standalone server offering some TCP
> commands?

Ugly, ugly. :)
Communication with shared memory would be possible and reasonable fast, 
but such is only available on Unix.
I see not much benefit of an external board window application, there is 
a lot of communication going on between the board and the core, so it 
should be IMO in the same process else things will be very complex. If 
one wants 3D, why not simply use glGo? After all glGo isn't anything 
else than gGo-in-C++ (well, at least it will be when it's done). The 
huge advantage of gGo and Java is its portability to any platform which 
supports Java (especially OS X as I don't have a Mac myself), therefor 
gGo will remain a pure Java application without any platform dependant code.


  Peter

Other related posts: