Crafty has been doing that or ages, right? In the root.

It really looks awful. If no one told you that before, there must be virtually no interest in it at all.

The pieces are not standing in the center of the squares, but seem to be just haphazardly thrown on the board by a blind person.
Furthermore, the board is drawn in perspective viewed at an angle ...

It seems the Apps are simply wrong. Note that Stockfish and HIARCS are UCI engines, which cannot claim draws at all. So the draw verdict must come from the GUI, and apparently this is buggy. Does this also happen when the move leading to the first occurrence is a non-capture? If not, than the bug is ...

I know little about Roce, but the normal way to hunt down perft discrepancies is to do a 'split perft', which does not only give the total number of counts for a given root position, but details this per move or per move sequence. Qperft allows splitting at any level; e.g.

$ ./perft 4 -3 "8/4K3 ...

Thanks Harm. I agree, if you are hashing the null move fail high it would create an inconsistency when beta changes and you do a TT cutoff based on a null move that would not have been attempted. I guess one question that comes to mind is...could you return the nullValue but not store the fail-high ...

I have a new favorite scheme, which uses 'undercut replacement' for some slots. Each position can be stored in 3 locations. If it is in one of the 3 already, it stays there (hit). If it isn't in any of the 3 (miss), it goes, in order of priority:
1) into the 3rd slot if its depth is larger than or ...

First priority should be to get a good setup for testing against other engines; fail-hard vs fail-soft is totally unimportant compared to that...

Null-move pruning is usually only attempted when staticEval >= beta. In that case it is better to return beta when the null move scores above it. If you ...

Why not just use an engine that already prints the moves in coordinate notation. There must be hundreds of those. All UCI engines,for starters.

Could also be that Crafty is 3.3 times faster than your engine, so that the overhead that is 33% for Crafty is only 10% for you. Still, there seems no reason to despise these 10%.

The bucket entry could look like this:
struct _HashBucket { // 64 bytes = 1 cache line
t_int32 signature[5];
t_int32 ...

You measured that on Crafty? I am just relaying what Bob reported, not so very long ago. Even then, 10% speedup, basically for free, is a very good deal.

You should not compare the time-to-depth between using a hash table and using no hash table at all, but between hash table and a hash table of ...