move generation with one dimensional "12 x 10" arr

[tvrzsky]

Personally I think traditional 0x88 is obsolete. You must test the square number first in order to see if its on the board, but you are in most cases going to access the contents of the square anyway to see if the square is empty. If I was going to do a mailbox approach, I'd do 12x16.

What is it 12x16?
I use 0x88 but such way that I have guards (guard pieces) in front as well as next the board array as well between the files of the board, like this:

Code: Select all

board visualisation (x is a guard piece):

xxA8xB8xOxOxOxOxOxH8xx
xxA7xB7xOxOxOxOxOx Oxx
xxA6xB6xOxOxOxOxOx Oxx
xxA5xB5xOxOxOxOxOx Oxx
xxA4xB4xOxOxOxOxOx Oxx
xxA3xB3xOxOxOxOxOx Oxx
xxA2xB2xOxOxOxOxOx Oxx
xxA1xB1xOxOxOxOxOxH1xx

which gets stored in memory:

xxxxxxxxxxxxxxxxA1A2A3A4A5A6A7A8xxxxxxxxB1-B8 ........... xxxxxxxxH1-H8xxxxxxxxxxxxxxx

so I have a choice to use both 0x88 and mailbox approach as necessary.
Isn't it a common practice?
Filip

[Zach Wegner]

That's a rather unconventional way of visualizing the board, but that is similar to what I describe. The difference is that your board is only 10x16. If there were no knights, your approach would be fine. But correct me if I'm wrong, knights on the A and H files would jump to squares off the board were it not for the 0x88 test. Adding another 16-rank file on each side allows you to bypass the 0x88 test altogether.

[tvrzsky]

That's a rather unconventional way of visualizing the board, but that is similar to what I describe. The difference is that your board is only 10x16. If there were no knights, your approach would be fine. But correct me if I'm wrong, knights on the A and H files would jump to squares off the board were it not for the 0x88 test. Adding another 16-rank file on each side allows you to bypass the 0x88 test altogether.

I am affraid my visualisation was not exact enough ...
Basically it is one large area of guards (in fact I have more than 16, just to be sure ) and then 8 bytes board, 8 bytes guards, 8 bytes board and so on and after that another large area of guards.
At least it is the way I think of it. I really dont know whether it is 10x16 or what however I don't see any 10 there .... It takes 120 bytes without outer guards and indexes are the same like in 0x88.
And anyway for move generation I use bitboards but knights works fine here.

[bob]

Personally I think traditional 0x88 is obsolete. You must test the square number first in order to see if its on the board, but you are in most cases going to access the contents of the square anyway to see if the square is empty. If I was going to do a mailbox approach, I'd do 12x16.

If that were the only benefit I agree. But the ability to ask "are these two squares on the same diagonal" and get an answer that does not break due to wrap-around is a plus for attack detection.

[Zach Wegner]

Read again. 12x16 you can do that too. It's just 0x88 plus two extra ranks (or files, if you're like Filip ) on the top and bottom of the board so that square coordinates don't have to be tested first before the board is accessed. Having 15 or more files allows the direction test as well.

[Zach Wegner]

I am affraid my visualisation was not exact enough ...
Basically it is one large area of guards (in fact I have more than 16, just to be sure ) and then 8 bytes board, 8 bytes guards, 8 bytes board and so on and after that another large area of guards.
At least it is the way I think of it. I really dont know whether it is 10x16 or what however I don't see any 10 there .... It takes 120 bytes without outer guards and indexes are the same like in 0x88.
And anyway for move generation I use bitboards but knights works fine here.

OK, if you have more than 16 guard squares then you are OK (specifically 25, if my head is counting correctly). Bitboards and an Xx16 board is an interesting combination. I used to use bitboards + 0x88, but got rid of the 0x88, as it wasn't being used. What do you use it for?

[tvrzsky]

I am affraid my visualisation was not exact enough ...
Basically it is one large area of guards (in fact I have more than 16, just to be sure ) and then 8 bytes board, 8 bytes guards, 8 bytes board and so on and after that another large area of guards.
At least it is the way I think of it. I really dont know whether it is 10x16 or what however I don't see any 10 there .... It takes 120 bytes without outer guards and indexes are the same like in 0x88.
And anyway for move generation I use bitboards but knights works fine here.

OK, if you have more than 16 guard squares then you are OK (specifically 25, if my head is counting correctly). Bitboards and an Xx16 board is an interesting combination. I used to use bitboards + 0x88, but got rid of the 0x88, as it wasn't being used. What do you use it for?

Mostly in evaluation but generally elsewhere, even my move generator is a combination of bitboards and ?XxXX? (I always used to think about it beeing an ordinary 0x88, so let's call it just sliding). Bitboards for generating of moves, sliding for checking for legality (I have legal moves generator). Sliding for checking whether the move was a check though I have almost got rid of it recently because I detect check possibilities during the move generation now (with an exception of check replies). Some tasks are simplier for me to solve using bitboards, some not. Frankly speaking I am not able to imagine doing things solely with bitboards. And I am 32bit only so there is some performance penalty with bitboards.
P. S. The most important feature of 0x88 for me is what has been mentioned by Bob, namely questions about geometry of board (differences of square indexes are constant).

[Steelman]

To answer your question.

I have defined the following:

#define EMPTY 0
#define OFFBOARD 1
#define WHITE_PAWN 2
#define WHITE_KNIGHT 3
#define WHITE_BISHOP 4
#define WHITE_ROOK 5
#define WHITE_QUEEN 6
#define WHITE_KING 7
#define BLACK_PAWN 8
#define BLACK_KNIGHT 9
#define BLACK_BISHOP 10
#define BLACK_ROOK 11
#define BLACK_QUEEN 12
#define BLACK_KING 13
#define MAXBOARD 120

All the offboard square values is set to OFFBOARD.
Empty sqaures to EMPTY and so on.

My board is this:

struct p_struct *board[MAX_BOARD];

And init board looks like this:

offboard_ptr = (struct p_struct *) malloc(sizeof(struct p_struct));
offboard_ptr->piece_value = OFFBOARD;
offboard_ptr->piece_location = 0;
empty_board_ptr = (struct p_struct *) malloc(sizeof(struct p_struct));
empty_board_ptr->piece_value = EMPTY;
empty_board_ptr->piece_location = 0;

for (i=0; =<MAX_BOARD; i++)
{
board = (struct p_struct *) malloc(sizeof(struct p_struct));
board->board_ptr = offboard_ptr;
}
for (i=20; i<100; i+=10)
for (j=1; j<9; j++)
board[i + j]->board_ptr = empty_board_ptr;

Does this help?

[Aleks Peshkov]

IMO old Gnuchess table-based move generation with plain 8x8 board is better.

It is very cheap to covert 8x8 to x88 coordinates sq_x88 = sq + (sq & 070); in rare cases when you need 0x88 tricks.

[Roman Hartmann]

I'm using a 10x12 array like you describe.

The pieces have negative values for the black side and in order to cope with that I'm using color-dependent code for move generation. So I only need to check if a certain square <= 0 and I know that I can move/capture with a white piece on that square.
For the black side you would have to check on the target-square for a value >= 0 and that the square is not off the board.

I don't claim this is a good idea or an efficient way to do that and having two different routines doing the same thing isn't exactly clever but I'm doing it anyway.

best regards
Roman