Now we add functionality for displaying chess positions on the board. Input to the process is in the form of a fen string to be pasted into a JTextField. Then we click on the fen button, and the proper position is displayed on the board. Right now the pieces are kind of crude in appearance, but that will change soon enough.
Anyways, we have a number of new constructs...
The position array is of type int, one entry for each square on the board. The choice of int is an important one, and will be explained shortly.
A new interface, Pieces, which for now provides both identity and value, as follows:
type white black --------------------- king 1 -1 queen 90 -90 rook 50 -50 bishop 30 -30 knight 29 -29 pawn 10 -10
these integers serve to identify the pieces, and also represent their value. Later, when the engine wants to calculate the material balance, it need only add up the position array. Making all the values a multiple of 10 allows for flexibility in tweking the values based on positional considerations. The Pieces interface will be implemented by any class that needs to know about the pieces. Sticklers will say i should have used an Enum here, maybe I'll switch sometime down the road.
A new class, Utils, which will contain static methods used by all parts of the program. Right now these methods contain methods which support the transformation of a fen position string into the internal position array. At the point we need the means to map back and forth between a few types of notation e.g.
the rank and file algebraic notation of the chess world top left = h8, bottom right = h1, maps to row column array notation (0,0) to (7,7) which maps to single dimension position array notation (0-63), which maps to the xy pixel co-rdinates of the upper left corner of each square on the chessboard.
A number of methods have ben added to the Board class in support of all this activity. The current piece design involves creating blank, transparent BufferedImage objects for each piece type, then associating a graphics context with the image, drawing primitives on this context, then drawing the image to the screen. You might well ask: Why not just draw the primitives directly to the drawing surface? Well the reason is that the way I have described facilitates easy switching between primitive or GeneralPath shapes, and externally created image files. In all cases it is an image we are drawing to the empty chessboard, and thus the paintComponent method is simplified.
Anyways, i have just provided a high level desription of what is going on. If you scrutinize the source code you can work out the actual details yourself.
As always, you have access to the source code and an up to date applet by following the link below.
Have a nice day.