Hacker News new | past | comments | ask | show | jobs | submit login

I appreciate the humor and tone for sure,

but I am perplexed by the assertion that confirming or checking-for `check` (as opposed to mate) is difficult.

Why is it not simply checking the attack surface of each piece from its current position? I understand there is occlusion, but that should be well-defined for collision-checking for taking already.

I.e. is this not the rule: "if none of the opposing 16 positions has the king's [prospective] position in their range of attack, the position is clear." Where range-of-attack are already defined.

If there is a problem with determining if a given range is subset by occlusion, that would seem to make preclude determining capture?

I must be missing something...




No, you are correct, it should be some "fairly straightforward"* 2D linear algebra to check for intersection (knight might need a special case). You just iterate all pieces and check for king collision box overlap with certain lines extended from enemy pieces. But OP states they are an EE and aren't the best at version control, so they probably haven't worked through this yet.

* again, straightforward if you have experience with computer rendering, CV, or similar domains, but less so in other domains.


The problem is that it needs to check every position that the king can move to as well. Doing it based on pixels would be extremely slow, and doing it based on the math seems like a nightmare, unless I am missing something.


You would not do it by pixels, it's pure math. I'd have to sit down and work through the actual math, but between convolution and affine transformations, I'm pretty sure there should be a way to compute the intersection with a formula for each piece type.

Knight is the easiest, that's just checking (lol) the distance to see if 5-r/2 <= d < 5+r/2.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: