******************************
 Laser Chess bugs and caveats 
 (c) 1997-2002 by Eric Tucker 
******************************


Bugs in Laser Chess
===================

These are bugs which I need to fix in my code.

1. Timer skew.  The timing mechanism currently used is very crude: we
set a timer once per second, and whenever the timer goes off, we
decrement the number of seconds left by one.  Also, in a networked
game, each computer keeps track of its own time.  This is sloppy and
can cause timers to get out of synch.  To fix this:

	- Look at the system clock to determine how much time has
	  really elapsed.  The timer ticks should be nothing more
	  than cues to update the display.  This affects how we deal
	  with game pauses too.

	- In a networked game, the computer whose player has control
	  should be the time "master", and send timing updates to the
	  other computer.

	- Suspend the timer during explosions, and during the mandatory
	  minimum "hang time" that a laser beam persists before going
	  away.

2. If a turn in a networked game ends in an explosion and the computer
whose turn it is about to be runs the explosion much faster, and that
player gets control and starts making moves before the other computer
realizes its turn is over, the keystrokes will be lost and the games
will get out of synch.

3. Laser Chess does not deal gracefully if one of the ports it wants
to use for a networked game is already in use.  There should be a
mechanism by which an alternate set of ports can be chosen.

4. The "Pick up"/"Put down" button and menu item should be disabled
when this action isn't valid, rather than just beeping when you select
them.


Bugs in the JDK
===============

I most recently tested Laser Chess on a 700MHz Pentium III with
128 megs of RAM running Windows 2000 with service pack 2 and JRE 1.4,
but have not reverified all of the bugs below in that environment.
Some of them were last observed in earlier versions of the JDK/JRE,
and it is possible that some of them have gone away by now.

1. The line spacing in the keyboard configuration dialog is excessive.
This is just how AWT static text labels are; they're packed as tightly
as it would let me.  I couldn't find a multi-line text label that
wasn't editable by the user.

2. When I upgraded from JDK 1.1.2 to 1.1.3, the cursor of the opponent
in a networked game stopped being redrawn correctly.  I think I was
doing everything by the book so it looks like an AWT redraw bug.  I
managed to force a redraw by superficially changing the labels at the
top of the screen every time the cursor moved.  I checked again in JDK
1.2.2 and the bug persists.  Since AWT clears the text label area
before redrawing, this causes an annoying flicker as the cursor moves
about the screen.  I could fix this by using a canvas that I draw onto
using double buffering, but it hardly seems worth it.

3. Disabling a filled-in radio button leaves the black circle solid,
which was misleading in my network configuration dialog.  I subclassed
the radio button class (really "Checkbox") so that it would clear
itself when disabled, and reinstate the filled circle when reenabled.
Although the AWT docs say that "at most one [radio button in a radio
button group] can be in the 'on' state at any given time", what they
have implemented is that EXACTLY one must be on, so if you try to
clear the last one, it ignores you.  I first tried getting around this
by taking the buttons out of the group, but then they revert to
looking like square checkboxes.  The docs also say that if you pass
the group a "null" for its currently selected radio button, it will
ignore you.  But fortunately, they are wrong about this too!  That did
what I wanted.  So basically, there are two bugs in AWT, and I am
depending on one of them as a workaround for the other.

4. Buttons are sized according to their initial labels.  If you later
make the label bigger, the size does not adjust.  Even if we
initialize them with the biggest label, and then change it back to the
one we really wanted before displaying it, it still manages to be too
small.  So the answer is to pad the shorter labels with whitespace, so
they are effectively longer.

5. On Linux and Solaris (perhaps all X-Windows-based Java ports?)
buttons and dialog boxes default their background color to black,
which is, coincidentally, the same color as the text on them!  So
unless you explicitly override this, text on buttons and in dialogs is
unreadable.

6. On the Mac, Graphics.setClip(null) does not clear the clipping
region; instead it generates an exception.

7. If we put up a dialog, when that dialog is dismissed, the board
gets the focus back (because we request it) but then promptly loses it
"permanently", and I can't figure what other component gained the
focus!  So when a dialog is put up, the board listens for permanent
focus lost events and grabs it back, just once.  (If we continued to
grab it back, it would make it impossible for the user to press any of
the buttons on the button bar, since that also involves a "permanent"
loss of focus!)

8. Once we play any sounds, the regular system beep ceases to work.
So when we want to beep, we have to play our own sound, which means
the user won't hear the standard system beep they have configured in
their OS.

9. If you move a dialog around quickly on top of the main Laser Chess
board, bits and pieces of that dialog may be leftover.  Whenever I get
a paint() event, I redraw the entire board, so this seems to be a bug
in the clipping region it sets before asking me to paint myself.  The
bug doesn't come up if you move the dialog box slowly; it is mostly
only for large, sudden movements.
