Tamerlane Chess

[Evert]

Yeah, porting ChessV to Linux would be fairly hard, but it should run under WINE - it uses very few Windows APIs, really only the most basic stuff. It's not worth doing any development on, though. The code base is a mess. It was my first attempt at any kind of chess program, and I went whole-hog with a universal chess engine and integrated GUI. It was too ambitious for a first project and it shows.

Well, being able to run it under Wine doesn't help if all I have is source code.

The replacement is two separate components - A new GUI written in C# which will run any winboard protocol engine, and a new winboard protocol engine written in C++. The GUI is in a very advanced state of development and is close to a state where it could be released. The engine is much farther off. I should be focusing on the GUI and releasing that first, but I've been more interested in the engine recently. It will definitely be compilable under Linux as that's how I'm developing it.

An independent GUI sounds awesome - especially one that allows for general variants. I think PyChess has variant support, but not configurable.

I've decided to abandon Windows because I'm seriously pissed off about the direction Microsoft has chosen to go. Windows 10 being basically a spyware operating system. It reads your personal documents and emails and gives you targeted ads. I expect that from Google because their stuff is free. I pay for Windows so that I don't have to deal with that. I've been a huge Microsoft fan for decades and now they've lost me. And if they've lost me, it's hard to believe they have any fans left. But both my government and major corporations are spying on us constantly and there seems to be little outrage and absolutely no willingness to abandon the slightest convenience in favor of privacy.

I ditched Windows some 15 years ago, but I still use an Apple laptop; Apple isn't exactly better in most of these things. Even so, I tried to play a DVD through my wife's laptop. Can't be done - the ability to view a DVD requires an optional non-free download in recent versions of Windows. Or an open source alternative. Guess what I used.

So going Linux is my first concrete step. I have two machines - one running Mint and one running Qubes. I like Qubes due to it's ultra-secure design; it's very promising but still a little rough around the edges and I am no Linux guru by any stretch so I have difficulty getting it to do things. Mint has been an absolute breeze to get everything I want installed and running. I think any moderately sophisticated Windows user could make the switch to Linux Mint with very little hardship.

Question - what development environment do guys use for your C/C++? I'm using CodeLite at the moment, and it is acceptable. It's a big step back from Visual Studio though (the only Windows program I really miss.) I tried Eclipse but that thing was way too big and slow. Just scrolling would cause refresh jitters and I'm on a modern i7. I also tried Code::Blocks but the ctrl+tab document switching doesn't behave correctly and that was a deal-breaker for me right there; I use that constantly...

You won't like it. I use Vim+terminal.
I've never used an IDE for C/C++, so all I ever had to do was pick an editor. I picked Vim because I wanted something that worked the same on my Linux machine and my laptop and wasn't called Emacs.

Back when I switched away from Windows, the only piece of software I really missed was my editor (Boxer 99). I'm reasonably efficient with Vim these days but I wouldn't call myself an expert.

[hgm]

..., but Windows has native functions for reading PNG files, I think?).

Well, not that I know. But my knowledge of WinBoard API is basically restricted to what WinBoard uses, as I never did any other GUI project for Windows.

Cairo seems to have functions for rendering directly to a Windows surface, so it should be possible to do the conversion on the fly, without needing GTK. Lacking Windows, I obviously don't have any personal experience with this though.

Well, if you would need GTK, you might as well compile XBoard for Windows.

Even if that is too much work, it seems worthwhile to make an external utility to convert the SVG images to the required Windows bitmaps.

The problem is that the windows bitmaps do not seem to support transparency. And to write anti-aliased pieces on the board you need to mix the edge of the piece (which should always be black) with the background (which even in the simple-color theme depends on square shade). The plot library that WinBoard uses cannot do that. But perhaps I could write code that does combine the bitmap pixels by hand. I already did that for XBoard, to make the SVG pieces subject to the pieceColor options.

Well, I'm not much of an expert on what would be needed for large variants of Shogi. Looking at it from a different perspective, I wonder if it is worthwhile to have something to represent the different "basic" leapers: WFNAZC are taken care of, what about D, H and G?

The reason that G and H are used for these moves is that there doesn't seem to be any existing piece that (just) does that move.

For D I guess most variants use the "crowned rook", but it might make sense to add an alternate (a catapult, say?).

I don't know how to draw a catapult with sufficiently low resolution. But the newly added Tower symbol could serve that purpose, because indeed I don't like using the Crowned Rook for this.

I don't know what H and G would best be represented as. It appears that a case could be made for including a Giraffe in the menagerie (we have Zebras, Gnus and Lions already). Other than that... perhaps a Bow&arrow or a Chariot?

Giraffe seems OK and doable (i.e. easily recognizable at pretty low resolution). Things like bow and arrow or trident are problematic, as it is difficult to make a black/white distinction in those. (This was of course also a problem with the Zebra, for different reasons.) The usual way to represent a Chariot is by a wheel (at least in the westernized Xiangqi sets I have seen). I already have made SVG for two (chiral) wheels. With what we have now plus the Wheels I have already enough for Macadamia Shogi (at the price of using the glyphs that in Shogi are used for pieces promoted to Gold for the sliding version they promote to now, which doesn't move anything like Gold). Add the chiral Shields and the Butterfly, and I have enough for Cashew Shogi too. With images in shorter supply than piece types I could of course make the promotion Golds, which now are only used as replacements during variant shogi, generally available.

The compound pieces for the most part look very silly (although I actually like the Amazon), but they help visualise the move. I disagree about 50x50 being a good size though, it becomes really blurry when scaled on a high-resolution display. It's sortof ok, but it's not very future-proof.

Your display must be much better than mine. With 49x49 squares even a normal 8x8 board leaves little room to spare vertically, on my Linux virtual machine...

[F. Bluemers]

On linux I use gcc with Sublime text.Not really an "environment" but a decent step up from "ed"

[hgm]

Yet I still often use 'ed'. When I want to do a complex transformation, like turning the output of an 'ls -l' command in a script that converts SVG to PNG of a certain size, nothing beats the regular expressions.

[Evert]

..., but Windows has native functions for reading PNG files, I think?).

Well, not that I know. But my knowledge of WinBoard API is basically restricted to what WinBoard uses, as I never did any other GUI project for Windows.

Apparently you can load PNG files directly into an HBITMAP (including transparency) using GDI+. None of the examples I could find looked especially "simple" to me, but I get the impression that most Windows API calls require a ton of boiler plate code to work.
It also seems to require C++, which isn't necessarily bad (you can call C++ functions from C) but doesn't make things easier.

Cairo seems to have functions for rendering directly to a Windows surface, so it should be possible to do the conversion on the fly, without needing GTK. Lacking Windows, I obviously don't have any personal experience with this though.

Well, if you would need GTK, you might as well compile XBoard for Windows.

Indeed, but as I said: fortunately Cairo is a separate thing.

Well, I'm not much of an expert on what would be needed for large variants of Shogi. Looking at it from a different perspective, I wonder if it is worthwhile to have something to represent the different "basic" leapers: WFNAZC are taken care of, what about D, H and G?

The reason that G and H are used for these moves is that there doesn't seem to be any existing piece that (just) does that move.

Hmm... ok, I see. To be honest it doesn't look like they would make terribly interesting pieces.

Giraffe seems OK and doable (i.e. easily recognizable at pretty low resolution). Things like bow and arrow or trident are problematic, as it is difficult to make a black/white distinction in those. (This was of course also a problem with the Zebra, for different reasons.) The usual way to represent a Chariot is by a wheel (at least in the westernized Xiangqi sets I have seen). I already have made SVG for two (chiral) wheels. With what we have now plus the Wheels I have already enough for Macadamia Shogi (at the price of using the glyphs that in Shogi are used for pieces promoted to Gold for the sliding version they promote to now, which doesn't move anything like Gold). Add the chiral Shields and the Butterfly, and I have enough for Cashew Shogi too. With images in shorter supply than piece types I could of course make the promotion Golds, which now are only used as replacements during variant shogi, generally available.

Now that you mention it, I did wonder how to get some of those. If it's not much hassle exposing those should add a couple of extra pieces. The downside is that they're not really usable as anything other than different Golds because they look too similar otherwise.

Your display must be much better than mine. With 49x49 squares even a normal 8x8 board leaves little room to spare vertically, on my Linux virtual machine...

Not on my desktop (which is 1280x1024), but my laptop has what Apple calls a "retina display". That means a display resolution of 2560x1600, but instead of advertising it as such everyone pretends that it's 1280x800, but if the program is "retina-aware" it can still use the higher resolution. So you get a UI that is scaled as for a 1280x800 display, but fonts and images all have 4x the resolution. It's really nice for pictures and text.
Of course programs that aren't "retina-aware" just get rendered at the lower resolution and upscaled poorly - which looks blurry and generally awful.

[Greg Strong]

BTW, since you are doing WB protocol, did you follow the latest developments of the protocol aimed at improving support for arbitrary Chess variants? In particular the engine->GUI 'piece' commands to reprogram the GUI's move generator through an XBetza description (since about a year), and (since about two days) the 'choice' command to control the promotion popup (or whatever method the GUI uses to let the user enter promotions)? And the somewhat older 'highlight protocol' ('highlight', 'lift' and 'put' commands, that started in the Alien Edition, but is now also incorporated in the standard edition)?

Excellent, thanks for bringing me up to speed. I knew about the highlighting protocol, but not the more recent advances. You've been busy - a Betza parser and everything. Great work!

Having the engine direct the GUI is contrary to my primary approach - the GUI knows everything and enforces everything. I've spent literally years coming up with the best object-oriented architecture I could devise to make addition of new variants as simple as possible. Pieces, boards, rules, are practically plug-and-play (or as close as I can get.) Adding support for the overwhelming majority of variants should take a matter of minutes.

That said, adding all variants isn't likely to happen, particularly really strange ones, so allowing it to go the other way, (the engine knows the rules and gives low-level directions to the GUI), makes sense as an alternative. I will need to add some sort of "alien mode" for supporting arbitrary variant the GUI doesn't know about. This isn't likely to be in the first version, though. All the winboard-automation code is ported from CuteChess, which wasn't designed with this kind of communication envisioned, although the CuteChess code is super object-oriented and well-designed (which is why I chose it) so it should't be too bad.

[Greg Strong]

Yeah, porting ChessV to Linux would be fairly hard, but it should run under WINE - it uses very few Windows APIs, really only the most basic stuff. It's not worth doing any development on, though. The code base is a mess. It was my first attempt at any kind of chess program, and I went whole-hog with a universal chess engine and integrated GUI. It was too ambitious for a first project and it shows.

Well, being able to run it under Wine doesn't help if all I have is source code.

Ahhh... Well, there I can help! Sam Trenholme has been generously hosting ChessV for me for years since I haven't gotten around to setting up my own website. You can download everything here: http://samiam.org/chessv/

The replacement is two separate components - A new GUI written in C# which will run any winboard protocol engine, and a new winboard protocol engine written in C++. The GUI is in a very advanced state of development and is close to a state where it could be released. The engine is much farther off. I should be focusing on the GUI and releasing that first, but I've been more interested in the engine recently. It will definitely be compilable under Linux as that's how I'm developing it.

An independent GUI sounds awesome - especially one that allows for general variants. I think PyChess has variant support, but not configurable.

Although it's designed to be really easy to add support for new variants, that currently requires re-compile, but support for external scripting will be forthcoming. And, someday, the Winboard approach of allowing the engine to dictate to the GUI. I really should put this out there somewhere in its current state. Although there are some parts that aren't complete, it's already totally functional for most things. Need to establish some web hosting, though. So much to do...

You won't like it. I use Vim+terminal.
I've never used an IDE for C/C++, so all I ever had to do was pick an editor. I picked Vim because I wanted something that worked the same on my Linux machine and my laptop and wasn't called Emacs.

Back when I switched away from Windows, the only piece of software I really missed was my editor (Boxer 99). I'm reasonably efficient with Vim these days but I wouldn't call myself an expert.

Wow. All three responders use plain text editors. I'm sure this is a really basic question, but how do you debug without an IDE?

[hgm]

Well, I got a bit tired of having to change the GUI all the time when a new variant had to be added. An engine would have to know the rules in any case, so why do duplicate work, and program them in the GUI too? So it seemed a good idea to have the engine do that programming. Then people could build whatever engine they wanted, without needing me to do anything about the GUI.

[hgm]

I'm sure this is a really basic question, but how do you debug without an IDE?

printf();

And in engines if(PATH)printf(); to print only in the node where things go awry.

[Evert]

Wow. All three responders use plain text editors. I'm sure this is a really basic question, but how do you debug without an IDE?

Depends a bit on what I'm debugging. Some combination of printf() and gdb.
I also try to use assert() consistently, but that doesn't help with all types of bugs.