ArnoHu ArnoHu loading

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

I’ve had enough stalling… I’m switching to list-contains in the evaluation and removing mate evaluations entirely unless a mate is found. Then, the TTable is toggled off and mate evals are turned on (or I gradually reduce the depth with the TTable List-Contains). Element desperately needs LMR to keeps up with White Dove’s tactical vision. Thoughts?

Not sure I understand correctly about TT mate evaluations, but I know they can be challenging. LMR is important from a certain search depth on.
I can’t fix the TT mate eval issue, so I’m removing them when the TTable is on. The LMR is to keep up with White Dove’s search depth. Detecting king captures in the evaluation will cause issues…

Quick question; why are move generation lookups faster than the more standard method? The latter uses numerical calculations, so it should be faster.

Hm, the standard move generation method on any other platform would be bitboards. As we don't have 64bit integers nor bitwise ops, what comes closest are precalculated lookup tables, as they limit the number of Scratch blocks invoked, which is the most important performance factor on Scratch 3. On TurboWarp that is not the case, but lookup tables should also be faster than additional logic code.