Hmmm... what do we have here? An update?
http://www.beyondwonderland.com/data/java/xiego/xiego.jnlp
Is it a major update? Hell no.
But it is enough to get into more, and more interesting technical details.
This little thing now keeps a state of the go board, aka goban, in the shape of an object oriented representation
of such a board.
This is still an empty shell btw, no way to play yet, but we're getting there for two players, human or computer.
What's challenging here is that, pretty much like javascripts, everything is drawn by the cpu,
and through an interpreter (the Java VM, still not as fast as a native program/binary/exe file - but getting there).
Since the stones now have a state, the whole layout must be redrawn each time a stone is added.
Meaning, in some of the tests I made, something like 1920x1200 pixel operations.
~~Gosh.
Plus it's a swing component in essence, in order for it to integrate user interfaces easilly.
I had to turn off the swing double buffering and ~gosh again, completely handle mine.
What this means is that I virtually could have an applet show the very same board, with the very same fine alpha blending
and interpolation.
Please pay attention to the word interpolation: at all times, all sprites are shrunken down versions of huge gif/jpeg files,
so everything is scaled on each redraw.
And I could pack all this in a 1920x1200 pixels banner applet
Also, there's a lot of clipping involved here, it's all "core" Java without specialties, core instructions, so to avoid overdraw and drawing the same pixel
n times, I clip my buffers between each sprite redrawal.
Think about it in terms of clipping your javascript/html "divs" to be able to display hundreds of them.
So yeah, it's 2d, it looks simple and silly, but it's packed with magic already, and finely crafted animations are up next.
In the end, it should stand 361 stones exploding at the same time.
Then we will plug the AI in, the network features, and.. ~pop~^ Oops. Blew a fuse. Is it 5AM? ~sigh.