Обеспечение всемирной трансляции спортивных шахматных соревнований с применением разработанного в ходе проекта законченного программного продукта
Характеристика структурного подразделения "Шахматный клуб". Выбор основных методологий, инструментальных средств и расчет затрат на разработку специализированного шахматного программного обеспечения ИС "ШК". Оценка экономической эффективности проекта.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 29.06.2010 |
Размер файла | 5,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
#define DGT_SIZE_VERSION 5
/*
byte 0: DGT_MSG_VERSION
byte 1: LLH_SEVEN(DGT_SIZE_VERSION)
byte 2: LLL_SEVEN(DGT_SIZE_VERSION)
byte 3,4: Version in 2 bytes of 7 bits hexadecimal value
Byte 3: 0bbb bbbb with main version number MSB 7 bits
byte 4: 0bbb bbbb with sub version number LSB 7 bits
The value of the version is coded in binary
i.e. When the number is "1.02" the busadres will be
byte 3: 0000 0001 (0x01)
byte 4: 0000 0010 (0x02)
*/
#define DGT_MSG_EE_MOVES (MESSAGE_BIT|DGT_EE_MOVES)
/* DGT_SIZE_EE_MOVES is defined in dgt_ee1.h: current (0x2000-0x100+3) */
/*
message format:
byte 0: DGT_MSG_EE_MOVES
byte 1: LLH_SEVEN(DGT_SIZE_EE_MOVES)
byte 2: LLL_SEVEN(DGT_SIZE_EE_MOVES)
byte 3-end: field change storage stream: See defines below for contens
The DGT_MSG_EE_MOVES message contains the contens of the storage,
starting with the oldest data, until the last written changes, and will
always end with EE_EOF
*/
/*
Description of the EEPROM data storage and dump format
------------------------------------------------------
General: The internal EEPROM storage can be seen as a cyclic buffer with length
0x1f00 bytes, with one pointer, pointing to the last written byte in the buffer.
Only at this pointer location, data can be written, incrementing the pointer.
The written data always overwrites the oldest data.
In this buffer, sequentially messages are written. The messages are of various
length, from 1 byte to 5 bytes, specific for every message.
Various events generate a message that is written in the storage, in the
sequence as the events occur. When the buffer is downloaded and read, the event
messages can be found, starting with the oldest event, and the latest event in
the end of the buffer, followed by EE_EOF.
- At power-on, three tags EE_NOP are written, followed by a one-byte
EE_POWERUP message.
After this, an UPDATE_BOARD message is written (in virtually random sequence)
for every piece that is found on the board, at power-on.
When the board is equipped with a watchdog timer, and the watchdog times out,
an EE_WATCHDOG_ACTION is written and after that, the above described power-up
procedure takes place.
- When at any time a normal starting position for chess is found, with the
player for white having the board connector on his left hand, an EE_BEGINPOS tag
is written, and an EE_BEGINPOS_ROT tag is written when white has the
connector at his right hand (rotated)
- When 16 chess figures are found on the board, all in the A, B, G and H row,
which are not(!) in a normal chess starting position, the one-byte
EE_FOURROWS message is written, to be tolerant on erroneous placement and i.e. to be able to play the "Random Chess" as proposed by Bobby
Fischer. The exact position of the pieces has to be analyzed on the context: or found in the previous piece move messages, or found in the
coming piece move messages.
When an empty board is detected, the one-byte EE_EMPTYBOARD message is
written.
The above described detection of begin positions or empty-board has a certain
hysteresis: only after more than two pieces have been out of the begin
positions the search for begin positions is restarted, resulting in possibly
new tag writing. This to avoid flushing the buffer full with data, only because
of one bad positioned and flashing piece.
When the data of the internal storage are sent upon reception of the
DGT_SEND_EE_MOVES command, the one-byte EE_DOWNLOADED message is sent
On every detected change of piece positions this change is written to EEPROM
in a 2-byte message, which cover exactly the same data as is sent to the PC
in the UPDATE_BOARD mode.
The formatting of the 2-byte piece update tag is:
First byte: 0t0r nnnn (n is piece code, see before)
(piece code EMPTY when a piece is removed)
(t is recognition bit, always 1)
(r is reserved)
so the first byte of this tag is always in the
range 0x40 to 0x5f
Second byte: 00ii iiii (i = 0 to 63 (0x3f), the field number as
defined before)
NB: when one piece only is changing, the new value is overwrites the
piece update field described above, instead of generating a new message
in the internal storage.
The same kind of optimization is included for begin-position tags:
a EE_BEGINPOS or EE_BEGINPOS_ROT or EE_FOURROWS is not written, when
between the previous written tags and the new occurence of the begin-
situation only 2 or 1 piece were out of the tagged beginsituation.
On the pressing of the clock, the time of the halted clock is written in
a time message. It might be that when the moves are done very fast, the
storage is skipped. Note: the two clock sides are identified only by
left and right side of the clock: When the board is swapped, the clock
data are not (!) swapped.
The clock data are written on tumbler position change, so at the beginning
of the game, the game starting times will be lost.
Format of a three-byte time message:
First byte: 0uuf hhhh (f=1 for time in left clock screen, seen from the front)
( hhhh: hours, valued 0 to 9)
(uu recognition bits, both 1, so byte 0 has the
( value range of 0x60 to 0x69, or 0x70 to 0x79)
Second byte: 0MMM mmmm (MMM: Tens of minutes (range 0 to 5),
(mmmm: minute units, range 0 to 9)
Third byte: 0SSS ssss (SSS: tens of seconds, range 0-5)
(ssss: seconds units, range 0-9)
On the recognition of the first byte of a message: The above definitions
imply that the first byte of a message is always ranged
from 40-5f for a field change message, 60-69 or 70-79 for a time message,
and 6a to 6f, or 7a to 7f for a 1-byte message.
(all values hexadecimal)
*/
/* Definition of the one-byte EEPROM message codes */
#define EE_POWERUP 0x6a
#define EE_EOF 0x6b
#define EE_FOURROWS 0x6c
#define EE_EMPTYBOARD 0x6d
#define EE_DOWNLOADED 0x6e
#define EE_BEGINPOS 0x6f
#define EE_BEGINPOS_ROT 0x7a
#define EE_START_TAG 0x7b
#define EE_WATCHDOG_ACTION 0x7c
#define EE_NOP 0x7f
/* 7d and 7e reserved for future use*/
/*
Notes on the communication dynamics:
The squares of the board are sampled one by one, where a full scan takes
about 200-250 ms. Due to this scan time, it can be, that a piece that is
moved from square e.g. A2 to A3 can be seen on both squares, in the same
scan. On a next scan of course, the old position is not seen anymore.
When in UPDATE mode, this means, that the information on changes on the
squares can come in opposite sequence: first the new occurence is reported,
then the clearing of the old position is sent.
When a piece B on C4 is taken by piece A on B3, it can be that the following
changes are reported:
A on C4
Empty on B3
(and Empty on C4 is never seen)
An other extreme situation can occur e.g. when a queen on C1 takes a pawn
on C4. The reported changes can be (in sequence):
Empty on C4 (the pawn is taken by one hand)
Queen on C2
Queen on C3
Empty on C1
Empty on C2
Queen on C4
Empty on C3
For writing software it is important to take these dynamics into account.
Some effort needs to be made to reconstruct the actual moves of the pieces.
See also the programmers and users manual
Paragraph: Bus communication protocol
-------------------------------------
Differencens between busmode and single board mode:
* In bus mode, RS232 input and RS232 output are connected to all boards.
The RS232 output of the board is configured as a pull-up driver: with a
pull-down resistor on the RS232 pull-up line. Now all boards receive all
commands from the computer, and can all send data to the computer.
* In single board mode the board has a small incoming commands
buffer (10 bytes).
* The bus mode has only a one-command incoming commands buffer
* When entered in single board mode, the board status always switches to IDLE:
changes are not send automatically
Bus mode is default power up mode of the board. The board recognises
bus commands from the start.
However, single board commands are recognised and answered.
The board switches to single board mode on the moment, a single board
command is recognised. Switching back to bus mode is invoked by the
extra command DGT_TO_BUSMODE or by sending a busmode command. (NB This
busmode command causing the swithing is not processed!)
For all detailed hardware descriptions: call.
*/
/* one added functon for swiching to busmode by command: */
#define DGT_TO_BUSMODE 0x4a
/*
This is an addition on the other single-board commands. This command is
recognised in single-board mode. The RS232 output goes in
pull-up mode and bus commands are immediatly recognised hereafter.
Note that when the board is in single-board mode, and eventually a bus
mode command is found, this command is not processed, but the board
switches to bus mode. The next (bus) command is processed regularly.*/
/* Bus mode commands: */
#define DGT_BUS_SEND_CLK (0x01 | MESSAGE_BIT)
#define DGT_BUS_SEND_BRD (0x02 | MESSAGE_BIT)
#define DGT_BUS_SEND_CHANGES (0x03 | MESSAGE_BIT)
#define DGT_BUS_REPEAT_CHANGES (0x04 | MESSAGE_BIT)
#define DGT_BUS_SET_START_GAME (0x05 | MESSAGE_BIT)
#define DGT_BUS_SEND_FROM_START (0x06 | MESSAGE_BIT)
#define DGT_BUS_PING (0x07 | MESSAGE_BIT)
#define DGT_BUS_END_BUSMODE (0x08 | MESSAGE_BIT)
#define DGT_BUS_RESET (0x09 | MESSAGE_BIT)
#define DGT_BUS_IGNORE_NEXT_BUS_PING (0x0a | MESSAGE_BIT)
#define DGT_BUS_SEND_VERSION (0x0b | MESSAGE_BIT)
// extra return headers for bus mode:
#define DGT_MSG_BUS_BRD_DUMP (0x03 | MESSAGE_BIT)
#define DGT_MSG_BUS_BWTIME (0x04 | MESSAGE_BIT)
#define DGT_MSG_BUS_UPDATE (0x05 | MESSAGE_BIT)
#define DGT_MSG_BUS_FROM_START (0x06 | MESSAGE_BIT)
#define DGT_MSG_BUS_PING (0x07 | MESSAGE_BIT)
#define DGT_MSG_BUS_START_GAME_WRITTEN (0x08 | MESSAGE_BIT)
#define DGT_MSG_BUS_VERSION (0x09 | MESSAGE_BIT)
// extra defines for bus length info:
#define DGT_SIZE_BUS_PING 6
#define DGT_SIZE_BUS_START_GAME_WRITTEN 6
#define DGT_SIZE_BUS_VERSION 8 // was 6 up to version 1.2
/* Definition of different commands&data
All commands DGT_BUS_xx have the following format:
byte 1: command, i.e. DGT_BUS_SEND_BDR (D7 always 1)
byte 2: MSB of addressed board (D7 always 0)
byte 3: LSB of addressed board (D7 always 0)
byte 4: checksum: this is the sum of all bytes from start of the message
upto the last byte before the checksum. (D7 always 0)
I.e. message code 0x81 0x10 0x06 will carry checksum byte 0x17
DGT_BUS_SEND_CLK
asks for clock information of addressed board.
Will result in a DGT_MSG_BUS_BWTIME message from the board.
DGT_BUS_SEND_BRD
asks for a board dump of addressed board.
Will result in a DGT_MSG_BUS_BRD_DUMP message from the board.
DGT_BUS_SEND_CHANGES
asks for all stored information changes from the moment of the last
DGT_BUS_SEND_CHANGES. Will result in a DGT_MSG_BUS_UPDATE message from
the board.
In case these data do not arrive properly, the data can be asked again
with the DGT_BUS_REPEAT_CHANGES command.
DGT_BUS_REPEAT_CHANGES
Causes the board to send last sent packet of changes again.
DGT_BUS_SET_START_GAME
sets an EE_START_TAG tag in the internal board changes buffer, for use in the
following command DGT_BUS_SEND_FROM_START. After this EE_START_TAG the
positions of the pieces are all logged in the file.
The command is answered with a DGT_MSG_BUS_START_GAME_WRITTEN message,
about 70 msec. after receipt of DGT_BUS_SET_START_GAME
DGT_BUS_SEND_FROM_START
causes the board to send a DGT_MSG_BUS_FROM_START message, containing
all update information starting with EE_START_TAG until the last registered
changes (excluding the moves that are to be sent with the DGT_BUS_SEND_CHANGES
command). Remember that after the EE_START_TAG all piece positions are written
in the eeprom file.
DGT_BUS_PING
causes the addressed board to send a DGT_MSG_BUS_PING message.
NB: when the DGT_BUS_PING command is sent with board address 0 (zero )
all connected boards will reply with a DGT_MSG_BUS_PING message, randomly
spread over a 1100 msec. interval. This to avoid collision. For reliable
identification of all connected boards, this process should be repeated
sometimes with checking of checksums!
DGT_IGNORE_NEXT_BUS_PING
is used in the process of detecting connected boards on a bus. After this
command (which itself sends a DGT_MSG_BUS_PING as handshake) the first
following DGT_BUS_PING with address zero (!) is ignored. This command
can be used to suppress response of already detected boards, and decreases
the chance of bus collisions.
This command responds immediately with a DGT_MSG_BUS_PING.
DGT_BUS_END_BUSMODE
causes the board to quit busmode, and go into single-connection mode.
Be careful not to use this command in a multiple board configuration!
NOTE: Any single-board command arriving during bus mode will
switch a board to single-board mode and will be processed. When sent
with address 0 the command is processed on all connected boards
DGT_BUS_RESET
forces a power-up reset procedure. NB: this procedure takes some seconds.
When sent with address 0 the command is processed on all conected boards
DEFINITION OF THE MESSAGE DATA FORMATS FROM BOARD TO PC
-------------------------------------------------------
General: the message format is:
byte 1: message type byte (MSB = 1)
byte 2: message length MSB (from byte 1 to checksum) (D7=0)
byte 3: message length LSB (containing D0 to D6 of the length (D7 = 0)
byte 4: board address MSB (D7=0)
byte 5: board address LSB (D7=0)
< data bytes: 0 to theoretically 16K-6 bytes >
last byte: checksum. This is the sum of all byte values from byte 1 to
the byte before this checksum. D7 is forced to 0
DGT_MSG_BUS_BRD_DUMP
the data area contains the piece codes from field 1 to field 64, in format
identical as the single board command
DGT_MSG_BUS_BWTIME
the data area contains the clock time information, in format identical as
the single board command
DGT_MSG_BUS_UPDATE
the data area contains a variable amount of change information, formatted
as described in the DGT_DUMP_EEMOVES message
DGT_MSG_BUS_FROM_START
the data area contains a variable amount of change information, formatted
as described in the DGT_DUMP_EEMOVES message
DGT_MSG_BUS_PING
the data area is empty: a message of 6 bytes is returned.
DGT_MSG_BUS_START_GAME_WRITTEN
The same format as for DGT_MSG_BUS_PING
DGT_MSG_BUS_VERSION
The two data bytes contain binary version number: first byte main number
second byte sub number.
Tips for usage of the bus mode:
A. On connection of power and starting of the communication process:
- Check communication with addressed DGT_BUS_PING commands to all expected
boards.
LOOP:
- Send DGT_BUS_IGNORE_NEXT_PING to all found boards
- Check eventually extra boards or unknown board busnumbers by using
a DGT_BUS_PING with address zero.
- Register the found boards, and go to LOOP:, until no more boards are found
B. At the start of an event: when all boards have pieces in starting
position, send DGT_BUS_SET_START_GAME commands to all boards.
- Read full clock times from all boards.
C. During a game: send DGT_BUS_SEND_CHANGES to all boards sequentially,
once every few seconds. The returned data should logically match
with the expected piece positions. When any mismatch occurs: ask full
position with DGT_BUS_SEND_BRD.
D. When previous data are lost: send a DGT_BUS_SEND_FROM_START command
which returns the full registered changes from the starting position.
On every sent message: The responce time at the board is within milliseconds
normally, except when the board is storing a measured change in the
internal EEPROM: Then the responce time can be up to 20 milliseconds.
So allow a time-out on sent messages of say 80 mS.
Checksum errors: when a received checksum does not match, resend the command
except on the DGT_BUS_SEND_CHANGES: then the command DGT_BUS_REPEAT_CHANGES
should be used, to avoid discarding of the changes sent by the board.
On clock data:
- reading data out of the clock and make them available
for communication causes a delay of up to 1 second between clock display
and received data.
*/
#endif
Приложение Ж
Общая структура транслятора шахматных партий
Приложение З
Общая структура регистратора шахматных партий
Приложение И
Анализ результатов тестовых испытаний
№ п/п |
Показатель |
Абсолютный количественный показатель |
Относительный количественный показатель в % |
Степень соответствия условиям соревновательного процесса (субъективная оценка главного арбитра соревнований) |
|
1 |
Количество сбоев в работе СШПО в ходе всего сорев-новательного про-цесса |
0 |
- |
ПОЛНОСТЬЮ СООТВЕТСТВУЕТ |
|
2 |
Количество вре-менных простоев в работе СШПО в ходе всего сорев-новательного про-цесса |
0 |
- |
ПОЛНОСТЬЮ СООТВЕТСТВУЕТ |
|
3 |
Количество несоот-ветствий отобража-емого хода ходу, сделанному на ша-хматной доске |
5 |
0,48 |
ПОЛНОСТЬЮ СООТВЕТСТВУЕТ |
|
4 |
Количество вре-менных задержек в ходе отображения игрового процесса |
1 |
0,01 |
ПОЛНОСТЬЮ СООТВЕТСТВУЕТ |
|
5 |
Количество вре-менных задержек переноса шахмат-ных партий в элек-тронную форму |
1 |
0,01 |
ПОЛНОСТЬЮ СООТВЕТСТВУЕТ |
Директор СП «ШК» Амзоров А.М.
Главный арбитр соревнований Федоров В.Н.
Приложение К
Листинг модуля вещания шахматных партий
// Фигура
var Figure = {
create: function(color, type, vertical) {
function figure() {}
var self = new figure();
self.id = color + type + vertical;
self.image = document.createElement('img');
self.image.src = get_image_path() + (color + type + '.gif').toLowerCase();
self.image.size = '8x8';
return self;
}
};
// Поле доски
var Field = {
create: function(vertical, horizontal) {
function field() {}
var self = new field();
// Идентификатор поля, соответствует ячейке в таблице, являющейся шахматной доской
self.id = "field" + vertical + horizontal;
self.horizontal = horizontal;
self.vertical = vertical;
self.cell = $(self.id);
//
function v(letter) {
letter = letter.toLowerCase();
if(letter == 'a') {
return 1;
}
if(letter == 'b') {
return 2;
}
if(letter == 'c') {
return 3;
}
if(letter == 'd') {
return 4;
}
if(letter == 'e') {
return 5;
}
if(letter == 'f') {
return 6;
}
if(letter == 'g') {
return 7;
}
if(letter == 'h') {
return 8;
}
return 0;
}
var vv = v(self.vertical);
var hh = parseInt(self.horizontal);
function isWhite(summa) {
var is_white = (summa / 2) - (Math.floor(summa / 2)) == 0;
//log(summa + ' - ' + is_white);
return !is_white;
}
self.cell.className = isWhite(vv + hh) ? 'board_white_field' : 'board_black_field';
self.set_figure = function(figure) {
if(figure == null) {
log('null in ' + self.id);
}
self.delete_figure();
self.cell.appendChild(figure.image);
self.current_figure = figure;
}
self.init_figure = function(figure) {
self.set_figure(figure);
self.first_figure = figure;
self.last_figure = figure;
}
self.delete_figure = function() {
this.cell.innerHTML = "";
}
self.first_figure = null;
self.current_figure = null;
self.last_figure = null;
return self;
}
};
// Ход шахматной партии
var Move = {
create: function() {
function move() {}
var self = new move();
self.color = '';
self.next = null;
self.prev = null;
self.number = 0;
self.field_from = null;
self.field_to = null;
self.figure = null;
self.figure_dead = null;
self.is_short_castling = false;
self.is_long_castling = false;
self.forward = function() {
if(self.is_short_castling || self.is_long_castling) {
self.field_from[0].delete_figure();
self.field_from[1].delete_figure();
self.field_to[0].set_figure(self.figure[0]);
self.field_to[1].set_figure(self.figure[1]);
} else {
self.field_from.delete_figure();
self.field_to.set_figure(self.figure);
}
}
return self;
}
};
var Chess = {
version: "2.0",
refresh_delay: 2, // интервал времени между обновлениями позиции в секундах
repaint_delay: 0.5, // интервал времени между перерисовками позиции в секундах
moves: '/main/game_moves/1',
createBoard: function() {
var board = Board.create();
board.init();
return board;
},
createField: function(vertical, horizontal) {
var self = Field.create(vertical, horizontal);
return self;
},
createFigure: function(color, type, vertical) {
var self = Figure.create(color, type, vertical);
return self;
},
createMove: function() {
var self = Move.create();
return self;
}
};
// Шахматная доска
var Board = {
create: function() {
function board() { }
var self = new board();
self.white_number = 0;
self.black_number = 0;
self.first_move = null;
self.current_move = null;
self.last_move = null;
// Могут быть состояния
// listen - следить за ходом партий, отображаются актуальные ходы
// custom - наблюдатель выбрал произвольную позицию в партии и навигирует по партии свободно
self.status = 'listen';
self.fields = new Array(64);
self.figures = new Array(32);
self.all_moves = '';
// Обновление позиции
self.refresh = function() {
function existsMove(color, annotation) {
var move = getMove(color, annotation);
var exists = move != "******" && move != "";
return exists;
}
function getMove(color, annotation) {
var m = annotation.substring(color == 'w' ? 0 : 6, color == 'w' ? 6 : 12);
return m;
}
function isCastling(color, type, annotation) {
var move = getMove(color, annotation);
var castling = (type == 'short' ? move.substring(0, 3) == 'O-O' : move.substring(0, 5) == 'O-O-O');
return castling;
}
function getField(is_short, is_long, target, color, annotation) {
if(is_short || is_long) {
if(color == 'w') {
if(is_short) {
return new Array(self.fields[target == 'from' ? 4 : 6], self.fields[target == 'from' ? 7 : 5]);
}
if(is_long) {
return new Array(self.fields[target == 'from' ? 4 : 2], self.fields[target == 'from' ? 0 : 3]);
}
}
if(color == 'b') {
if(is_short) {
return new Array(self.fields[target == 'from' ? 60 : 62], self.fields[target == 'from' ? 63 : 61]);
}
if(is_long) {
return new Array(self.fields[target == 'from' ? 60 : 58], self.fields[target == 'from' ? 56 : 59]);
}
}
}
var field = annotation.substring(color == 'w' ? (target == 'from' ? 1 : 4) : (target == 'from' ? 7 : 10), color == 'w' ? (target == 'from' ? 3 : 6) : (target == 'from' ? 9 : 12));
var v = field.substring(0, 1).toLowerCase();
var h = field.substring(1, 2).toLowerCase();
//log('getField: v ' + v + ' h: ' + h);
var iField = (parseInt(h) - 1) * 8;
//log('tmp ' + iField);
if(v == 'b') {
iField += 1;
}
if(v == 'c') {
iField += 2;
}
if(v == 'd') {
iField += 3;
}
if(v == 'e') {
iField += 4;
}
if(v == 'f') {
iField += 5;
}
if(v == 'g') {
iField += 6;
}
if(v == 'h') {
iField += 7;
}
//log('return ' + iField);
return self.fields[iField];
}
function getFigure(is_short, is_long, target, color, field) {
if(is_short || is_long) {
if(color == 'w') {
if(is_short) {
return new Array(self.figures[0], self.figures[7]);
}
if(is_long) {
return new Array(self.figures[0], self.figures[6]);
}
}
if(color == 'b') {
if(is_short) {
return new Array(self.figures[16], self.figures[23]);
}
if(is_long) {
return new Array(self.figures[16], self.figures[22]);
}
}
}
if(target == 'alive') {
return field.last_figure;
}
if(target == 'dead') {
return field.last_figure;
}
}
// Запрашиваем обновление позиции
new Ajax.Request(Chess.moves, {
method: 'get',
onSuccess: function(transport) {
self.all_moves = transport.responseText;
}
});
// Анализируем ходы партии
var splits = self.all_moves.split('|');
var moves = new Array();
for(i = 0; i < splits.length; i++) {
if(splits[i] != null) {
moves.push(splits[i
}
}
// Количество полученных ходов
var number = moves.length;
var current_number = self.last_move == null ? 1 : self.last_move.number;
if(number == current_number && self.last_move != null && self.last_move.color == 'w') {
var move_annotation = moves[number - 1];
if(move_annotation != '' && existsMove('b', moves[number - 1])) {
var move = Chess.createMove();
move.is_short_castling = isCastling('b', 'short', move_annotation);
move.is_long_castling = isCastling('b', 'long', move_annotation);
move.field_from = getField(move.is_short_castling, move.is_long_castling, 'from' , 'b', move_annotation);
move.field_to = getField(move.is_short_castling, move.is_long_castling, 'to', 'b', move_annotation);
move.figure = getFigure(move.is_short_castling, move.is_long_castling, 'alive', 'b', move.field_from);
move.figure_dead = getFigure(false, false, 'dead', 'b', move.field_to);
move.number = self.last_move != null ? ('b' == 'w' ? (self.last_move.number + 1) : self.last_move.number) : 1;
move.color = 'b';
move.field_from.last_figure = null;
move.field_to.last_figure = move.figure;
move.prev = self.last_move;
if(self.last_move != null) {
self.last_move.next = move;
}
self.last_move = move;
self.changes = true;
}
}
if(number > current_number) {
var c = ['w', 'b'];
for(var iMove = current_number; iMove <= number; iMove++) {
for(var ic = 0; ic < c.length; ic++) {
var move_annotation = moves[iMove - 1];
if(existsMove(c[ic], move_annotation)) {
var move = Chess.createMove();
if(self.first_move == null) {
self.first_move = move;
}
move.is_short_castling = isCastling(c[ic], 'short', move_annotation);
move.is_long_castling = isCastling(c[ic], 'long', move_annotation);
move.field_from = getField(move.is_short_castling, move.is_long_castling, 'from' , c[ic], move_annotation);
move.field_to = getField(move.is_short_castling, move.is_long_castling, 'to', c[ic], move_annotation);
move.figure = getFigure(move.is_short_castling, move.is_long_castling, 'alive', c[ic], move.field_from);
move.figure_dead = getFigure(move.is_short_castling, move.is_long_castling, 'dead', c[ic], move.field_to);
move.number = self.last_move != null ? (c[ic] == 'w' ? (self.last_move.number + 1) : self.last_move.number) : 1;
move.color = c[ic];
var ff = move.field_from;
var ft = move.field_to;
var fg = move.figure;
if(fg == null) {
continue;
}
move.field_from.last_figure = null;
move.field_to.last_figure = move.figure;
move.prev = self.last_move;
if(self.last_move != null) {
self.last_move.next = move;
}
self.last_move = move;
self.changes = true;
}
}
}
}
}
self.changes = false;
// Перерисовка позиции
self.repaint = function() {
if(self.current_move == null) {
if(self.first_move == null) {
return;
}
self.current_move = self.first_move;
}
if(self.current_move.color == 'w' && self.white_number == self.current_move.number ||
self.current_move.color == 'b' && self.black_number == self.current_move.number) {
if(self.current_move.next != null) {
self.current_move = self.current_move.next;
}
return;
}
self.current_move.forward();
if(self.current_move.color == 'w') {
self.white_number++;
}
if(self.current_move.color == 'b') {
self.black_number++;
}
if(self.current_move.next != null) {
self.current_move = self.current_move.next;
}
}
// Инициализируем доску, создаем поля и фигуры
self.init = function() {
var v = new Array("A", "B", "C", "D", "E", "F", "G", "H");
var f = new Array("K", "Q", "B", "N", "R", "P");
var c = new Array("w", "b");
// Создаем представление доски - таблицу
var tableBoard = document.createElement('table');
tableBoard.border = 1;
tableBoard.align = "center";
tableBoard.width = "512px";
var tableBody = document.createElement('tbody');
tableBoard.appendChild(tableBody);
var tableDiv = $('board');
tableDiv.appendChild(tableBoard);
var rows = new Array(document.createElement('tr'), document.createElement('tr'), document.createElement('tr'), document.createElement('tr'),
document.createElement('tr'), document.createElement('tr'), document.createElement('tr'), document.createElement('tr'));
for(var iRow = 7; iRow >= 0; iRow--) {
tableBody.appendChild(rows[iRow]);
}
// создаем ячейки
for(var iVertical = 0; iVertical < 8; iVertical++) {
for(var iHorizontal = 8; iHorizontal > 0; iHorizontal--) {
var cell = document.createElement('td');
cell.width = '64px';//(100 / 8).toString() + "%";
cell.height = cell.width;
cell.align = 'center';
cell.id = "field" + v[iVertical] + iHorizontal.toString();
rows[iHorizontal - 1].appendChild(cell);
}
}
// поля
log('creating fields ...');
var iField = 0;
for(var iHorizontal = 1; iHorizontal < 9; iHorizontal++) {
for(var iVertical = 0; iVertical < 8; iVertical++) {
self.fields[iField] = Chess.createField(v[iVertical], iHorizontal.toString());
iField++;
}
}
log('creating figure ...');
// фигуры
self.figures[0] = Chess.createFigure(c[0], f[0], ''); // wk - 0
self.figures[1] = Chess.createFigure(c[0], f[1], ''); // wq - 1
self.figures[2] = Chess.createFigure(c[0], f[2], v[2]); // wbC - 2
self.figures[3] = Chess.createFigure(c[0], f[2], v[5]); // wbF - 3
self.figures[4] = Chess.createFigure(c[0], f[3], v[1]); // wnB - 4
self.figures[5] = Chess.createFigure(c[0], f[3], v[6]); // wnG - 5
self.figures[6] = Chess.createFigure(c[0], f[4], v[0]); // wrA - 6
self.figures[7] = Chess.createFigure(c[0], f[4], v[7]); // wrH - 7
self.figures[8] = Chess.createFigure(c[0], f[5], v[0]); // wpA - 8
self.figures[9] = Chess.createFigure(c[0], f[5], v[1]); // wpB - 9
self.figures[10] = Chess.createFigure(c[0], f[5], v[2]); // wpC - 10
self.figures[11] = Chess.createFigure(c[0], f[5], v[3]); // wpD - 11
self.figures[12] = Chess.createFigure(c[0], f[5], v[4]); // wpE - 12
self.figures[13] = Chess.createFigure(c[0], f[5], v[5]); // wpF - 13
self.figures[14] = Chess.createFigure(c[0], f[5], v[6]); // wpG - 14
self.figures[15] = Chess.createFigure(c[0], f[5], v[7]); // wpH - 15
self.figures[16] = Chess.createFigure(c[1], f[0], ''); // bk - 16
self.figures[17] = Chess.createFigure(c[1], f[1], ''); // bq - 17
self.figures[18] = Chess.createFigure(c[1], f[2], v[2]); // bbC - 18
self.figures[19] = Chess.createFigure(c[1], f[2], v[5]); // bbF - 19
self.figures[20] = Chess.createFigure(c[1], f[3], v[1]); // bnB - 20
self.figures[21] = Chess.createFigure(c[1], f[3], v[6]); // bnG - 21
self.figures[22] = Chess.createFigure(c[1], f[4], v[0]); // brA - 22
self.figures[23] = Chess.createFigure(c[1], f[4], v[7]); // brH - 23
self.figures[24] = Chess.createFigure(c[1], f[5], v[0]); // bpA - 24
self.figures[25] = Chess.createFigure(c[1], f[5], v[1]); // bpB - 25
self.figures[26] = Chess.createFigure(c[1], f[5], v[2]); // bpC - 26
self.figures[27] = Chess.createFigure(c[1], f[5], v[3]); // bpD - 27
self.figures[28] = Chess.createFigure(c[1], f[5], v[4]); // bpE - 28
self.figures[29] = Chess.createFigure(c[1], f[5], v[5]); // bpF - 29
self.figures[30] = Chess.createFigure(c[1], f[5], v[6]); // bpG - 30
self.figures[31] = Chess.createFigure(c[1], f[5], v[7]); // bpH - 31
// расставляем исходную позицию
self.set_begin_position();
}
self.set_begin_position = function() {
log('initialize begin position ...');
self.fields[56].init_figure(self.figures[22]);
self.fields[57].init_figure(self.figures[20]);
self.fields[58].init_figure(self.figures[18]);
self.fields[59].init_figure(self.figures[17]);
self.fields[60].init_figure(self.figures[16]);
self.fields[61].init_figure(self.figures[19]);
self.fields[62].init_figure(self.figures[21]);
self.fields[63].init_figure(self.figures[23]);
self.fields[48].init_figure(self.figures[24]);
self.fields[49].init_figure(self.figures[25]);
self.fields[50].init_figure(self.figures[26]);
self.fields[51].init_figure(self.figures[27]);
self.fields[52].init_figure(self.figures[28]);
self.fields[53].init_figure(self.figures[29]);
self.fields[54].init_figure(self.figures[30]);
self.fields[55].init_figure(self.figures[31]);
self.fields[8].init_figure(self.figures[8]);
self.fields[9].init_figure(self.figures[9]);
self.fields[10].init_figure(self.figures[10]);
self.fields[11].init_figure(self.figures[11]);
self.fields[12].init_figure(self.figures[12]);
self.fields[13].init_figure(self.figures[13]);
self.fields[14].init_figure(self.figures[14]);
self.fields[15].init_figure(self.figures[15]);
self.fields[0].init_figure(self.figures[6]);
self.fields[1].init_figure(self.figures[4]);
self.fields[2].init_figure(self.figures[2]);
self.fields[3].init_figure(self.figures[1]);
self.fields[4].init_figure(self.figures[0]);
self.fields[5].init_figure(self.figures[3]);
self.fields[6].init_figure(self.figures[5]);
self.fields[7].init_figure(self.figures[7]);
}
self.set_end_position = function() {
}
self.set_position = function(number, color) {
}
self.next_move = function() {
}
self.prev_move = function() {
}
return self;
}
};
var board = Chess.createBoard();
// Периодическое обновление позиции
new PeriodicalExecuter(board.refresh, Chess.refresh_delay);
// Периодическая перерисовка позиции
new PeriodicalExecuter(board.repaint, Chess.repaint_delay)
Подобные документы
Модель этапа пост-архитектуры. Предварительная оценка программного проекта на основе LOC-метрик. Расчет затрат на разработку ПО. Стоимость, длительность разработки проекта на основе модели этапа пост-архитектуры конструктивной модели стоимости СОСОМО II.
курсовая работа [89,9 K], добавлен 29.09.2009Требования к функциям и задачам, выполняемым системой "Подбор кредита ОАО "Россельхозбанк". Проектирование архитектуры программного продукта. Структурная схема программного продукта. Описание компонент программного обеспечения. План менеджмента проекта.
курсовая работа [684,0 K], добавлен 03.05.2015Характеристика программного продукта и стадий разработки. Расчет затрат на разработку и договорной цены, эксплуатационных расходов, связанных с использованием нового программного продукта. Оценка конкурентоспособности. Изучение, оценка рыночного спроса.
курсовая работа [139,0 K], добавлен 22.09.2008Информационное обеспечение задачи автоматизации учета. Программное обеспечение задачи автоматизации учета. Расчет технико-экономической эффективности программного продукта по учету пластиковых карт. Расчет затрат на разработку программного модуля.
дипломная работа [2,1 M], добавлен 10.02.2018Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
отчет по практике [296,1 K], добавлен 19.04.2015Разработка программного обеспечения для микропроцессорных систем МК51, интерфейсы в системах связи, основы асинхронной связи. Этапы решения задачи на ЭВМ, принципы тестирования программ и их отладка. Расчет затрат на разработку программного продукта.
дипломная работа [270,6 K], добавлен 19.06.2010Расчет издержек предприятия на разработку программного продукта и экономической эффективности от его внедрения. Топология физических связей и структуризация сети. Характеристика программного обеспечения. Средства автоматизации, описание алгоритма задачи.
дипломная работа [867,6 K], добавлен 05.11.2015Создание программного продукта для учета и просмотра информации о товаре, поступающем на склад организации ООО "Риф" на языках программирования PHP и MySQL. Руководство по работе с программой. Расчет экономической эффективности разработанного проекта.
дипломная работа [549,9 K], добавлен 21.06.2011Анализ существующего программного обеспечения. Этапы создания проекта. Концептуальное, логическое и физическое проектирование базы данных. Структура программного продукта. Руководство программиста и оператора. Тестирование программного продукта.
курсовая работа [586,4 K], добавлен 26.06.2015Изучение основных видов угроз программного обеспечения. Выявление наиболее эффективных средств и методов защиты программного обеспечения. Анализ их достоинств и недостатков. Описания особенностей лицензирования и патентования программного обеспечения.
курсовая работа [67,9 K], добавлен 29.05.2013