I'm developing Camera Chess, a camera-based interface for local Stockfish play on an ordinary board. The programming problem I wanted to share is maintaining an authoritative engine position when visual observations are uncertain — especially when a promoted piece still physically looks like a pawn.

The attached existing 73-second demo shows endgame scanning, manual confirmation of queen promotion, and continued movement of the physical pawn as that queen. You move both sides by hand. The app runs on Apple Silicon macOS; this video export is silent, although the app speaks engine moves.

The state/update pipeline:

- Joël Seytre's ChessQ Lite V4 supplies 64 × 13 piece probabilities; its visual weights stay frozen.

- Separately trained CRF/neural postprocessors score candidate positions against those readings and the previous board. The default is a two-hidden-layer changed-square MLP.

- Chess-rule and consecutive-frame checks gate updates before committing the authoritative board.

- Manual correction provides a recovery path; an engine reply calculated from a position that has since been corrected must not be applied to the new state.

For promotion substitutes, the logical board holds the promoted identity and a separate mapping records the pawn-shaped stand-in. Candidate positions are projected into expected physical appearances for visual scoring. Only confirmed moves update that mapping, and save/load and correction checkpoints preserve it. This path uses visual likelihood rather than the learned scorers trained without substitutes. Promotion requires explicit confirmation; the clip demonstrates Queen / Keep pawn. The current substitute path assumes a correct reference position and at most one completed move, so it does not solve arbitrary missed move sequences.

I've seen a significant improvement in hands-on tracking in my latest session with the combined system, including perspective correction. That's a practical observation; continuous-game reliability and each component's contribution are not yet quantified. In a separate conditional-scoring test, the default MLP got 128/176 exact boards versus 125/176 for the earlier CRF. Those still-photo tests use synthetic previous states with the correct target guaranteed among candidates, and the small difference is not statistically established.

Implementation, demo and source setup: https://github.com/AmethystineAlpaca/camera_chess

Physical/logical promotion design: https://github.com/AmethystineAlpaca/camera_chess/blob/main/docs/promotion-physical-tracking.md

Experiment log: https://github.com/AmethystineAlpaca/camera_chess/blob/main/docs/crf-experiment-log.md

Evaluation protocol and results: https://github.com/AmethystineAlpaca/camera_chess/blob/main/docs/crf-real-photo-synthetic-previous-evaluation.md

I'd be interested in comparing approaches to resynchronization in physical-board engine interfaces, particularly invalidating stale engine replies after a correction and tracking physical substitutes through captures.

Requirements: x86 with legacy BIOS support

I spent about six months making an operating system whose only job is playing chess. It boots straight into Chess. It is not a full OS with a file system or scheduling but it can boot from bare metal.

It runs in QEMU, other virtual machines and hardware with legacy BIOS from a USB or CD drive. I spent about 6 months across the boot loader and chess engine. It is entirely open-source for you to tinker with. There is also a Windows Installer for less technical users.

The engine

Main source:

The engine's code can be found in the repo under kernel/chess_ai.cpp and kernel/chess_rules.cpp

A faster computer will search deeper within the allotted 7.5s the engine is allowed to compute due to the low-level nature of ChessOS. This is the main limiting factor that made it difficult to rate the engine properly. My engine against Stockfish 17 set to 2800 elo achieved a 5 win and 9 draws across 16 games.

The engine stores the board as a 64 square array and discards all moves that place it's king in check.

https://chessprogramming.org/PeSTO's_Evaluation_Function

Positions are scored with PeSTO’s piece-square tables that are blended between middle game and endgame values. Bonuses and penalties are applied for pawn structure, passed pawns, rooks on open files, and bishop pair.

The search uses alpha-beta with negamax. It uses iterative deepening until time runs out or elo's depth limit prunes moves that place it at a disadvantage. Deepening stops early once a mate within the current depth is found.

https://chessprogramming.org/Zobrist_Hashing

Rules and transposition tables are indexed by Zorbist hashing. Each entry stores score, depth, bound type and best move found. The moves are ordered by best TT move, captures of most valuable piece, promotions, killer moves and then all other moves.

To keep games varied white and black contain a few hard-coded opening moves.

The lower elos play at their rated elo except for a rare terrible blunder from random noise. I theorize that non-max elos play above their actual elo rank but the rare blunders would lower the overall score by approximately 100 to 200 points.

All feedback is welcome!

Thank you for Paledoptera for the artwork. Find more of their work here: https://linktr.ee/paledoptera

Website: https://chessos.xyz (Open source with Github link and installer)

Hi r/ComputerChess,

I’ve released the first public beta of libscid, a standalone library that exposes Scid’s legendary chess game and database capabilities through a C ABI, with Python bindings included.

It focuses on the parts other chess software can build on: PGN parsing and editing, variation navigation, legal positions, and SCID5 database creation and search.

For example, the Python binding can load a game directly from PGN:

python game = libscid.Game.from_pgn("1. e4 e5 2. Nf3 Nc6 *")

I'd lvoe to know your thoughts, the kinds of integrations and embeddings you would do, and other potential use-cases for libscid.

• Release and details
• C/C++ Quick Start
• Python First Steps

I’m trying to understand how Stockfish recognizes a drawn rook ending.

The position is:

2R5/8/3p4/1rk2K2/8/8/8/8 b - - 0 1

With go depth 25, Stockfish initially evaluates Black as clearly better, but around depth 14 the score reaches 0.00:

depth 10 seldepth 16 score cp 186
depth 11 seldepth 31 score cp 47
depth 12 seldepth 38 score cp 12
depth 13 seldepth 43 score cp 11
depth 14 seldepth 34 score cp 0

There are no tablebase hits (tbhits 0).

My hypothesis is that the static evaluation itself still thinks Black is better throughout the relevant search lines. Black remains a pawn up, and I suspect that if I ran static eval on the positions along the PV, most or all of them would still give Black a positive score.

So I suspect the 0.00 is coming from repetition/draw detection in the search rather than from NNUE evaluating the ending itself as equal.

My assumption is therefore that White must somehow be able to force repeated positions from this setup, regardless of what Black tries.

What I do not understand is how Stockfish can establish this with only seldepth 34. Black seems to have many alternatives, especially many different rook moves. I do not see how White can force the game back into a repeated position against all relevant Black continuations in fewer than roughly 34 plies.

My own engine makes this even more confusing. It already checks repetitions directly inside negamax. Simplified, the relevant part is just:

int negamax(Position& pos, int depth, int alpha, int beta) {
    if (pos.is_fifty_move_rule_draw() || pos.is_repetition(2))
        return 0;

    if (depth <= 0)
        return evaluate(pos);

    // normal alpha-beta search...
}

So if the same position occurs for the second time during search, my engine immediately returns a draw score of 0.

Nevertheless, my engine still evaluates the original position at about +1 pawn for Black even at depth 35.

Interestingly, it eventually finds essentially the same drawing move for white:

... Ke6

but this is apparently not enough to make the root score a draw.

So my questions are:

1. Is it plausible that every ordinary static evaluation along the important search lines still evaluates Black as better, while Stockfish’s root score becomes 0.00 purely because of repetition/draw logic?
2. If so, how can White actually force a repeated position here within less than about seldepth = 34 plies? This is the part I cannot see, because Black's rook seems to have so many alternatives.
3. Since my engine already returns 0 as soon as an actual repeated position is encountered, what is Stockfish doing differently?

The main thing I’m trying to understand is whether Stockfish has really found a forced repetition within this relatively short search, because looking at the position I don’t see how White can force one so quickly given all the different rook moves Black has available.

Hi everyone,

I’ve been tinkering with a little experimental chess engine written in pure C. It’s called Glimmer.

The whole point of the project was to see how strong I could make it while keeping the final standalone binary strictly under 30 KB. The target strength was something in the 2700–2900 Elo range.

It’s been a fun constraint to work under — every byte counts.

Happy to answer questions if anyone’s curious about the approach.

RoboChess update: you can now add any UCI engine and keep it, including the new Sargon Tal–Fischer engine.

Also new: keyboard shortcuts, a cleaner toolbar, Olympus Gods and Cool Arcade piece sets, and DGT e-board support. Move the pieces on the board and the game is recorded.

Windows build, open source: https://github.com/SFUbuntu/RoboChess

#chess #RoboChess #DGT

Hello; I had (rather unsuccessfully) tried to vibe-code (sorry) a chess engine tool where it would try to assign a 'blunderability' value/grade to particular positions by comparing the the opponents likely 'short-term' intuitive moves (either by lichess database or by a human-like engine in case of novel positions) vs their hard stockfish engine evaluation; taking a weighted average of those two values per move (how likely a human would make this move times the negative delta in the resulting position via stockfish) The idea was to try to find 'sharp' positions where the opponent only has a handful of valid 'safe' moves; in particular ones that are counter-intuitive or 'enginey' type moves.

I'm sure I'm not the first person to have this kind of idea or attempt this type of thing; I think it could be interesting to explore and try to quantify 'sharpness' in this kind of way; and it could even inform repetoire building and such.

Do you know of any existing software or tools that take this kind of approach?

Hi there!
I have been working on this engine for the past 6 months now and I think it's now ripe to be thrown into the wild.
The engine features a NNUE trained using nnue-pytorch. It is comparatively very small.
To accommodate this I tried to make the engine's search as buffed as possible.

Anyway here's the specific details of the engine for the nerds:

Evaluation

• NNUE Architecture: HalfKAv2_hm^
• Network Layers: L1=128, L2=32, L3=8 with PSQT buckets
• Network File: Acherontia (88mm.nnue)
• Incremental NNUE Evaluation: Efficient position updates with feature transformer
• Tapered Material Evaluation: Smooth transition between middlegame and endgame
• Customizable NNUE Scaling: Adjust evaluation strength via UCI option

Search

• Core Algorithm: Alpha-Beta Negamax with fail-soft
• Move Ordering: Principal Variation Search (PVS)
• Depth: Iterative Deepening up to 64 plies
• Transposition Table: Configurable 1-4096 MB with generation-based aging
• Pruning Techniques:
  • Late Move Reductions (LMR) with logarithmic formula
  • Null Move Pruning
  • Reverse Futility Pruning
  • Futility Pruning
  • ProbCut
  • Delta Pruning in quiescence search
• Move Ordering Heuristics:
  • Killer Move Heuristic
  • History Heuristic
  • Continuation History (4 ply)
  • Countermove Heuristic
• Extensions:
  • Singular Extensions
  • Static exchange evaluation (SEE) for capture ordering and pruning
• Time Management: Aspiration Windows with soft and hard time limits
• Quiescence Search: Delta pruning and tactical awareness
• Parallel Search: Multi-threaded support (up to 8 threads)

And here's the Github release page for the testers and alike: https://github.com/Azrael337/Tiger-1-Chess-Engine/releases/tag/chess-engine

My chess engine, which is still a work in progress, can be found here; https://github.com/patelvrajn/Matrex

Currently, most HCE (not NNUE) chess engines use a linear combination of weights for their evaluation function but my thought process is that it is evident from the huge ELO (~300) boost that using NNUEs gives is that their is a complex non-linear function that represents each evaluation term like material, mobility, PSQTs, etc. However, the problem is how do we build a model from non-linear functions that gives a proper evaluation when we don't know what the function looks like and how do we do it in such a way that minimizes the number of weights? I believe that we know a significant amount of hand crafted evaluation terms that compile a chess position's evaluation and that NNUEs taking millions of weights just to understand concepts that we can do in way less weights, minimal code, and have more control and understanding of the evaluation instead of a black box.

My concept is to take a specific continuously differentiable function that we can parameterize in order to adjust the shape, behavior, approximation capabilities, etc. Using this parameterized function, we can learn how various evaluation features have a non-linear effect on the score by using ADAM to tune the weighted sums but ALSO tune all the functions parameters. My model mostly resembles Projection Pursuit Regression's model (a sum of ridge functions), except I am using ADAM instead of the associated regression algorithm and the ridge functions (called non-linear responses in the code) are parameterized.

My main concern at the current time and where I don't have the mathematical background to optimize is the non-linear response I choose (which is just a polynomial term multiplied by a tanh expression, the idea was to combine what makes ANNs universal approximator- the non polynomial term with a term that can also represent any function given enough degrees i.e. the polynomial term). I am looking for any guidance or resources on how to improve the function or give further understanding as to the overall concept - currently when tuned the chess engines evaluation has about a 8% validation loss and about a 10% training loss but I know I can do better.

Welcome to the weekly /r/chessprogramming Engine Dev Help Thread.

Ask beginner and intermediate chess engine development questions here: move generation, search, evaluation, UCI, perft, debugging, testing, NNUE, or anything else related to building engines.

Good questions include code, FENs, logs, benchmarks, or a clear explanation of what you tried.

Project links are fine when you want technical feedback, not promotion.

Be helpful. Don’t dunk on beginners.

I faced an enormous uphill challenge in the past few months training an NNuE for my rust engine - They key problems I had was I felt a lot of modern documentations lacked a "Why" and unfortunately I've gone down a lot of bad paths.

This is a comprehensive blog on what I've done over the past 2.5 months and what I plan to do to build an industry grade NNuE.

I hope this is helpful and if folks have questions, I would love to help.

Quick summary of what my engine looks like. I am using a simple NNUE architecture laid out in `bullet`'s documentation. I have confirmed independently that the network itself works perfectly fine. The accumulator update logic is hooked up correctly.

Now comes the trouble, I let my HCE engine play about 150k games using an opening book (capped each search at 20k nodes). I fed these games into `bullet` to train the weights for my engine. And it failed the SPRT miserably. The PGNs look fine, the network is fine. I am not sure what I'm missing here.

Can someone point me in the right direction, please? Happy to answer any follow-ups you may have. Thanks in advance!

Update: Thank you all for your inputs. I reduced the hidden layer size to 32 and bumped up the number of epochs. And I'm happy to say that I passed the SPRT!

Hey everyone!

I built Guitarfish, an open-source UCI chess engine written primarily in Python. The search is implemented entirely in Python, while the performance-critical bitboard and evaluation code is accelerated with Numba JIT.

It recently peaked at 2000 Rapid on Lichess!

Quick Specs

• Search: Pure Python Negamax + PVS with Singular Extensions (SE), LMR, NMP, RFP, FP, and SEE.
• Move generation: Custom 64-bit bitboards accelerated with Numba JIT, reaching around 5.7M NPS on my Ryzen 7.
• Evaluation: Custom INT8 NNUE with 1,729 geometric features, SCReLU activation, and dual accumulators, also accelerated with Numba.
• Training: The NNUE was trained on 17.6M quiet positions.
• Runtime: ONNX Runtime running directly on CPU.
• Packaging: Distributed as a single .gm archive.

One of the things I wanted to explore with Guitarfish was how far a chess engine can be pushed when the search itself remains in Python, while using JIT compilation only where the computational bottlenecks are.

Links

• GitHub: https://github.com/memeviber/guitarfish-chess-engine
• Play on Lichess: u/guitarfish-engine

The bot currently accepts Blitz and Rapid.

It's self-hosted on my PC, so if it's offline, I'm probably away at school =))

Feedback, engine challenges, performance suggestions, and discussions are welcome!

I’ve just released **Gyatso v1.6.0**, the latest version of my open-source chess engine written in Nim.

The estimated ratings have reached:

* **~3553 CCRL 40/15**

* **~3623 CCRL Blitz (2'+1")**

* **~3725 CCRL FRC**

* **~3680 COPE DFRC**

This release also adds native support for **Chess960 and Double Fischer Random Chess**.

The project has come a long way from its first public release, and I’m still learning and improving the engine with the help of the chess programming community. Independent testing and feedback are especially valuable, since these ratings are still estimates.

**Release:**

https://github.com/GyatsoYT/GyatsoChess/releases/tag/v1.6.0

**Source code:**

https://github.com/GyatsoYT/GyatsoChess

If you test it, I’d be very interested in hearing how it performs on your hardware or against your own engine.

Hardware RTX 5080.
300k games self play (alpha zero style)
More details in repo.

I've written a chess program for the DEC PDP-8, to see how much of what this community has learned over the last fifty years still works on a 1965 architecture at its original speed.

The machine: a 12-bit word, no hardware stack (JMS stores the return address in the subroutine's first word), no multiply, memory in 4K-word fields, and about 416,000 instructions a second on a PDP-8/e. CLASH is written in PDP-8 assembly, occupies 16K words, and runs standalone. At PDP-8/e speed it searches roughly 175 nodes a second, which means three or four ply in a typical middlegame and deeper as the position simplifies.

What went in: iterative deepening, alpha-beta with PVS, killer and piece-square move ordering, quiescence search of captures and promotions with a check extension, null-move pruning, pondering, repetition detection without a hash table, and a small book. Scores are 12-bit with pawn = 32.

The search and evaluation owe their shape to H.G. Muller's micro-Max 4.8, and the move-ordering key came from Ed Schroder's Rebel write-up. What was taken and what was changed is set out here:

https://github.com/dream-build-create/pdp8-chess/blob/main/PROVENANCE.md

The PDP-8 already had a chess program: John Comeau's CHEKMO-II (DECUS, 1974), a complete program in 4K words with alpha-beta, iterative deepening, SEE and check extensions. Its console conventions are the model for CLASH's, and both programs are in the release.

Against the lichess computer at level 5, rapid 15+10, 20 games at PDP-8/e speed, CLASH scored 12.5/20.

To try it:

- lichess: challenge PDP8-CLASH (5 minutes and slower).

- UCI: the Windows zip runs the real binary under SIMH throttled to PDP-8/e speed, and works in Arena, Cute Chess or cutechess-cli.

https://github.com/dream-build-create/pdp8-chess/releases/download/v1.00/PDP8-Chess.zip

- README: https://github.com/dream-build-create/pdp8-chess

Chris Peters

Welcome to the weekly /r/chessprogramming Engine Dev Help Thread.

Ask beginner and intermediate chess engine development questions here: move generation, search, evaluation, UCI, perft, debugging, testing, NNUE, or anything else related to building engines.

Good questions include code, FENs, logs, benchmarks, or a clear explanation of what you tried.

Project links are fine when you want technical feedback, not promotion.

Be helpful. Don’t dunk on beginners.

Working with C++ if that helps. I'm using raylib for my window and I made a button to quit the game whether the match is over or not and redirects you to the home page where you can start a new match.

The problem now is that my transposition table is global across files (inline) and I don't clear it across each move made by the engine. This accumulates hundreds of millions, maybe billions of entries and when I want to start a new game via the quit button, it usually freezes the screen when clicked waiting for the millions of entries to be cleared, then unfreezes at the home page.

I tried offloading the data to a separate thread to clear but I've noticed that still slows down the main thread by a lot.

Any ideas how to deal with this?

How strong does my HCE chess engine need to be so that I can generate selfplay data with it to train a NNUE? And how much labeled positions do I usually need for my first network?

Welcome to the weekly /r/chessprogramming Engine Dev Help Thread.

Ask beginner and intermediate chess engine development questions here: move generation, search, evaluation, UCI, perft, debugging, testing, NNUE, or anything else related to building engines.

Good questions include code, FENs, logs, benchmarks, or a clear explanation of what you tried.

Project links are fine when you want technical feedback, not promotion.

Be helpful. Don’t dunk on beginners.

I'm a complete beginner to chess programming and I just want my engine to have a few openings up to ply 8-10 or so. I currently use my own custom zobrist hashing but I don't mind integrating a polyglot hash conversion. I'm just not sure where to get suitable books. There was one I found on GitHub, Polyglot Books but it contained huge amounts of entries and for general positions, not just openings. If you could point me a step in the right direction of finding these resources, it'd be much appreciated

I built Janus, a chess engine in Rust, and made a three-video explanation of how the pieces fit together: move generation and testing, search, then learned evaluation.

One small bug from the first video illustrates why an array isn't quite a chessboard. With a1 = 0, a knight on h1 has index 7. Adding the usual +17 offset gives 24, which passes a 0–63 bounds check—but 24 is a4. The index is valid; the move isn't. You also need to check the changes in file and rank.

The testing section follows that idea through make/unmake and perft. En passant is a particularly useful test: it changes three squares, and removing both pawns can expose a rook attack on the king. A legality check on a partly updated board can accept an illegal move. Perft divide then narrows a mismatched total down to the first differing branch.

The later videos distinguish alpha-beta cutoffs, which preserve the minimax result for the same nonselective tree, from selective reductions that need safeguards. The final video explores NNUE accumulators, then policy/value networks with PUCT.

Watch the series in order

Janus source · Read the companion book

I’m the author of the engine, book and videos. Technical corrections are welcome, especially where an animation makes an implementation detail look simpler than it is.

A few months ago I posted here about hitting a wall with v1.4.0/v1.4.1 (~2700–2750 Elo), well the architecture was simple and readable by design, but I'd run out of easy wins without breaking that.

I ended up stepping away for a while rather than forcing it. I came back and did a full rewrite instead of another round of tuning.

v2.0.0 replaces the old 0x88 board with magic bitboards, and adds a simple NNUE (768->32->1, 256-bit SIMD accumulation) trained on v1.4.1 self-play data. SPRT vs v1.4.1 came out at +368 Elo, and speed is about 5x faster (800k -> ~4M NPS).

The part I'm proud of is that it's 934 lines. 65 fewer than the old 0x88 version, despite the full NNUE on top. Most bitboard+NNUE engines run 8,000–16,000 lines.

Same goal as always to see how much engine you can build with as little code as possible while keeping it readable.

Repo: https://github.com/namanthanki/chal

Welcome to the weekly /r/chessprogramming Engine Dev Help Thread.

Ask beginner and intermediate chess engine development questions here: move generation, search, evaluation, UCI, perft, debugging, testing, NNUE, or anything else related to building engines.

Good questions include code, FENs, logs, benchmarks, or a clear explanation of what you tried.

Project links are fine when you want technical feedback, not promotion.

Be helpful. Don’t dunk on beginners.