Castling and en-passants are encoded in the 4-bit "move type" described in the page I linked to. That plus 6-bit "to" and "from" gets you to 16 bits.
I used to do that in my old engine (Ruy-López), but that requires you to generate all the moves before you even try the move from the transposition tables. Since this move very often produces a beta cutoff, it's worth writing a function that checks validity of a move on a given position and try to avoid generating the move list altogether.[/size]
I use a 16-bit format for the move, as described here: [/size]http://chessprogramming.wikispaces.com/Encoding+Moves
That's sound cheaper than what I implemented now, I'll try.
You said that you can encode a move in 16 bit, but as far as I know the minimum is 32 bit (how do you manage castle and en passants?).
No, you can always convert to and from the 16-bit format just for transposition-table access. That shouldn't be too slow.
Omitting this, I made some test when i was working on the move generator and it came out that my move encoding (which is a class with 4 byte fields ) is faster than using a single 32 bit integer for representing it. Should I change encode method for saving some memory in the transposition table?
Now would be a good time. It's basically impossible to implement time control without it, and it's very hard to work with an engine that doesn't control time properly.
That's a very difficult question. A few ideas:[/size]
* You can run a search up to depth D (I assume you are using iterative deepening) and then rerun it without clearing the transposition tables: It should be almost instantaneous.[/size]
* You can run a long search on a position with and without transposition tables, and the version with transposition tables should generally get to the same depth faster.[/size]
* You can match your program against itself, with and without transposition tables, at a fixed depth, and the results should be even.[/size]
for trying point one I should first implement iterative deeping (when should i do that?).
Yup, that one is a biggie.
P.S. I've just implemented MVV-LVA and the search is now MUCH faster! thank you.