This is the coolest thing ever! it's a bit hard to play because black/white is not so easy to distinguish but you probably get used to it. (I lost cause I mixed up my knight with my opponents)
I remember using WinBoard (in Windows) or XBoard (in Linux) around 1998 or 1999 with to play chess on FICS after the novelty of the telnet experience wore off.
Honest question, is there any open source non-subscription based no-frill virtual chess board on Android that allows you to simply play chess offline against human or AI, in the same spirit as VLC on Android?
Not open source but chess.com app is brilliant, it's a freemium model - you can play for free - but they just keep trying to sell you tip and tutorials.
Also seems to have all the grand masters on there as players, Magnus ignored my request for a game though.
Looks good! In case anyone else wonders (first thing I wanted to know), UCI (to talk to engines and online chess) is in the to-do, not yet implemented.
There is a perfectly fine UCI crate available already, so it shouldn't take the author too too long. Unless they intend on implementing it themselves of course. But it's not a terribly complicated protocol either.
Borland Pascal 7 had a chess engine implementation in the EXAMPLES directory. There were two frontends in the same directory: one used OWL to provide a graphical interface in Windows, the other one was for MS-DOS (character-based) using the Turbo Vision library, and it was pretty awesome!
It has always bothered me that there are no Unicode code points for the left/right halves of chess pieces, which would enable a nearly square board using two characters per square.
This is a nice solution, but it makes for a rather big board.
Sorry, that didn't render. They're U+258C and U+2590. So you put them on either side and each square is rendered across 3 cells, and the 2 outer cells are half-blocks shared with the adjacent squares.
As a user I love it, I use a mix of Windows, Linux and MacOS machines and when I see docker I know that it will "just werk" regardless of which one I'm using at the moment
It’s just a distribution mechanism that users like. The page details other ways to install, including native methods. The container is at the top just because it will be the first thing many people will want to try.
I don't think I've ever liked the experience of running Docker commands; I think its benefit is the sandboxed environment so the developer has fewer platform variables they need to worry about. I think flatpak is a more user friendly distribution mechanism. But, again, sandboxing really shouldn't be necessary with a Rust TUI application; there really shouldn't be much in the way of platform-specific code in there except maybe the ncurses library
Commit 592de110d15c55512f8254b38051e3a61853eb82 looks weird. I don't have the time to read the code, but mod 9 instead of mod 8 in a chess-related program looks like the off-by-one has just been "fixed" in the wrong place.
Or sometimes Terminal, I've seen them used interchangeably though I find “Text” is more common.
Usually TUI is used in a way that implies not just a basic command line interface: something like a GUI (buttons, dialogs, navigable lists, frames, interactive text editing, etc) just drawn using “text” elements so it works via a terminal console. I've seen some people refer to almost any CLI or REPL as a TUI but while they match the words of the acronym (they are user interfaces based on text) I think this is incorrect and TUI refers to a more specific sub-set of text-based interfaces.
This is probably one of the most egregious "in rust" projects I've seen. Should I care about the performance improvements over something like Python in a program where I'm going to spend 99.999% of the time thinking? Should I be concerned about memory safety in other chess implementations written in C? The only thing Rust seems to add over Python or Go for things like this is making it harder to hack.
