If you're thinking in releasing your program for free, I hope that you'll use freeware Rybka 1.0.
well, he's programming a GUI and he just wants to communicate with the engine, no need to worry :)
This can all be seen at;
At the time I was writing a simple program for my own use only that would mine chess databases for tactics problems, so neither comment was of immediate relavance or use. However Felix Kling's comment did linger in my mind. Why not write my own chess GUI ? Every chess GUI I've ever used has seemed awkward to use. I wanted to be able to easily setup any position, specify any time control (giving myself a nice time advantage :~), and start playing with either colour against an engine. In the Fritz interface (for example) the engine would often seem to want to play the same side as me and I would have to wrestle with it! Certainly I couldn't change the clocks or the player names simply by clicking on them. Why not?
Plus there are features I've always wanted that I could now implement myself; Open book operation so that I can easily see the book moves available, see when the engine has used a book move, and indeed be prompted with the book move(s) if I play a non book move. Visualisation training with full and partial blindfold modes and a 'play N half moves behind' mode.
Anyway, whether it made sense or not, I went ahead and wrote my own chess GUI (for Windows only at this stage). I am proud of it and would like people to use it and let me know how they think it could be improved. It is available as a free download at http://triplehappy.com. The package includes a simple (weak) UCI engine I wrote specifically to accompany the GUI.
But the real point of this post is Vytron's comment above.
Can I just go ahead and include the freeware Rybka engine in my GUI package ? If I could do that I think I would be offering users the easiest path to a top class computer chess experience available anywhere.
The free Rybka .zip doesn't include any legal stuff at all. It would be great if Vas for example could officially confirm that I can go ahead and include Rybka v2.2n2.mp.w32.exe in my package and use it as my default engine.
Please note that freeware Rybka has been updated to 2.2n2, so you can include this much stronger version:
Are you taking GUI feature requests? I'm mainly interested in engine-engine tournament features that no other GUIs have at this time.
And yes I am absolutely taking feature requests. I know that most of the enthusiasts here are mainly into engine vs engine operation, but unfortunately my GUI at the moment only addresses human vs engine operation which has always been my main area of interest.
However there is absolutely no reason why I could not add engine vs engine, especially if someone can point out inadequacies in existing GUIs in this area, or otherwise help me determine a useful feature set.
> However there is absolutely no reason why I could not add engine vs engine, especially if someone can point out inadequacies in existing GUIs in this area, or otherwise help me determine a useful feature set.
- Match mode: This makes engine A play engine B a set number of games.
Current GUIs don't have an easy way of making the engine play against itself (AFAIK).
- Tournament mode: This allows several engines to play each other. Modes include:
Round Robin: Each engine plays all the other engines as white and as black.
Round Robin One color: As above but only as one color (the engine plays each opponent once.)
Gauntlet: The first engine on the list plays all the other engines as white and as black.
Single Gauntlet: As above, but the first engine gets white in all the games.
Swiss System: The engines play a set number of games. The system pairs the engines in some order:
Knock Out: The engines that lose a game (or draw it as white) are out of the tourney, the remaining engines continue until one engine is left, and it wins (usually for power of 2 participants such as 8, 16, 32...)
- Ability to start from PGN positions.
- Ability to save all tourney games to a PGN (saving detpht, time to move, expected move, etc.)
- Ability to watch the games in where one can see both engine's PVs, and their history.
GUIs like Aquarium doesn't have Gauntlet, ChessPartner doesn't have Swiss, nor KO, etc. I think many members would be willing to move to your GUI if you provide features their GUI are missing.
I will refer to your post above when (and if) I become motivated to add engine versus engine play. I don't see any particular difficulty in adding this to my GUI (although up until now I have basically ignored the issue of engine options, I would obviously need to address this before starting out on engine versus engine play), but of course it is far from trivial.
Basically my motiivation for improving the GUI will come from people using what I have already produced, and then providing feedback that encourages even greater efforts....
> In general I am not going to be able to compete with professional programming teams in feature count
Oh, but you can, you implement Gauntlet and you beat Aquarium, you implement Swiss System and you beat ChessPartner, and so on.
> Basically my motiivation for improving the GUI will come from people using what I have already produced, and then providing feedback that encourages even greater efforts....
Sorry, since I don't use the GUI to play against the engine I couldn't provide useful input.
> I am not going to be able to be produce class leading engine versus engine features in any kind of compressed time scale.
Don't worry, take your time, we aren't in a hurry :)
By the way, I had an idea for how you can force existing GUIs to run a match between two copies of the same engine;
Make a copy of the UCI .exe you are interested in and give this second copy a suitable name. So if you want RandomEnginev3.02 to play itself, copy RandomEnginev3.02.exe to RandomEnginev3.02Clone.exe say. Then use a hex editor to find the id string in RandomEnginev3.02Clone.exe and modify it appropriately. Beware that you'll only be able to overwrite some characters in the string, you won't be able to make the string longer.
I am pretty sure that then any GUI that does matches will let the engine and its clone do battle.
> I am pretty sure that then any GUI that does matches will let the engine and its clone do battle.
Yes, that's why I said they don't provide an "easy way" (not that it's impossible.)
Anyway, you're already ahead of Arena and Winboard (etc.) at the chessboard, your anti-aliased pieces look much better.
> - Match mode: This makes engine A play engine B a set number of games.
> Current GUIs don't have an easy way of making the engine play against itself (AFAIK).
> - Tournament mode: This allows several engines to play each other. Modes include:
> Round Robin: Each engine plays all the other engines as white and as black.
> Round Robin One color: As above but only as one color (the engine plays each opponent once.)
> Gauntlet: The first engine on the list plays all the other engines as white and as black.
> Single Gauntlet: As above, but the first engine gets white in all the games.
> Swiss System: The engines play a set number of games. The system pairs the engines in some order:
> Knock Out: The engines that lose a game (or draw it as white) are out of the tourney, the remaining engines continue until one engine is left, and it wins (usually for power of 2 participants such as 8, 16, 32...)
> - Ability to start from PGN positions.
> - Ability to save all tourney games to a PGN (saving detpht, time to move, expected move, etc.)
> - Ability to watch the games in where one can see both engine's PVs, and their history.
> GUIs like Aquarium doesn't have Gauntlet, ChessPartner doesn't have Swiss, nor KO, etc. I think many members would be willing to move to your GUI if you provide features their GUI are missing.
Have you tried ChessGui by Matthias Gemuh?
P.d. As spanish speakers when you write is in your TODO list, that sounds like a very largeeee, (tending to infinit vempele will say) list.
> GUIs like Aquarium doesn't have Gauntlet, ChessPartner doesn't have Swiss, nor KO, etc. I think many members would be willing to move to your GUI if you provide features their GUI are missing.
PSWBTM + WinBoard does have most of the features you request (match, single or double RR, gauntlet), or they would be trivial to add (fixed-color gauntlet, knockout, expected move in PGN). The only really hard thing is Swiss pairing, which is really a project in itself if you want to do it exactly according to the strict FIDE rules. (A reasonable approximation could be easily implemented, of course.)
> PSWBTM + WinBoard
I only use Winboard because it's the "lightweightest" GUI around, for quickly looking at games, if someone took care of the user friendliness (0 text files editing needed, or they appear for editing with one click, seamless UCI support, etc.) and made a package with everything needed installed, it could become my main GUI, but I don't think the developer(s) are taking such feature requests (e.g. a toolbar).
> A reasonable approximation could be easily implemented, of course.
Yeah, reasonable approximation would be enough.
>Anyway, whether it made sense or not, I went ahead and wrote my own chess GUI (for Windows only at this stage). I am proud of it and would like people to use it.
Tarrasch - Nice 'n' Simple!
Very Good Development.
Keep UP! :)
I see lot of potential of developments in Tarrasch.
As for now just one suggestion, as .bin (crafty and polyglot), .dat (thinker) and .scb (spike and slow chess) book format contains more data and details v/s size as compared to .pgn format. Probably you would like to implement same in near future.
Regarding including Rybka v2.2n2.mp.w32.exe, better to consult VAS directly.
Once I included Rybka v2.2n2.mp.w32.exe with WinBoard prior to his permission (but, VAS was quite OK with that) and posted a download link in CCRL Forum, which became an issue and finally I was got banned in some other forum too! But, here is pleasant part of it which is a token of appreciation from WinBoard plus Rybka lover.
If in near future Tarrash forms a very good shape as a GUI and remains free, probably VAS would also like to include Tarrasch to RybkaChess web-site along with Rybka v2.2n2.mp.w32.exe demo ( VAS confirmed to be fully functional) downloads.
This forum is full of volunteers for testing your GUI on numerous strong hardware. If so, just give a shout here! :). You can count on me too!
Thanks for sharing your development.
By the I like your approach.
Keep UP Good Works!!!
PS: The most beautiful part of Tarrasch is it does not mess up Windows registry unlike some other GUI do.
Vytron's opinion was that I could definitely go ahead and include the freeware Rybka 2.2 exe in my package, but you disagree. You suggest consulting with Vas directly, may I ask how I should do that ?
> You suggest consulting with Vas directly, may I ask how I should do that ?
I'll move this thread to main, then Vas will see it.
your GUI looks interesting. :)
If you can get it into a decent shape, we'd be more than happy to host it (with installation instructions) on this page:
Anyway, I will think about what getting the program into decent shape means, and then hopefully go ahead and get the program in decent shape :-) In the first instance I must address any and all issues raised in this thread to date. Maybe we can talk again in the future.
> The target audience is serious chess players who are not skilled computer users and so perhaps have missed the computer chess revolution so far. These users need everything to be as easy as possible. Also there are people who are skilled computer users who like to use simple and lightweight programs.
Indeed, you really can't go too far in this direction. Think iPod, Google, etc.
Indeed, you really can't go too far in this direction.
Believe me,Vas is not exaggerating in this matter. A small illustration if I may...how would one paste an entirely unrelated position into the Tarrasch GUI ?
I suppose the ultimate solution to this problem would be to allow the user to roughly highlight a foreign position in any program, then on request to use AI to interpret the graphical content of that position to discern first the ranks and files and then (the tricky part) decide which pieces are which (relying on the fact that bishops [say] tend to look like bishops whatever the font). Don't expect this feature in Tarrasch anytime soon!
> I suppose the ultimate solution to this problem would be to allow the user to roughly highlight a foreign position in any program, then on request to use AI to interpret the graphical content of that position to discern first the ranks and files and then (the tricky part) decide which pieces are which (relying on the fact that bishops [say] tend to look like bishops whatever the font). Don't expect this feature in Tarrasch anytime soon!
I think copying and pasting a FEN/EPD is simpler.
For that, DiagTransfer by A.Blaisot is a useful freeware tool:
It works like a kind of semitransparent overlay, for easy setup of a position shown on a webpage. It supports FEN, PGN, legality check, diagram printing... Looks great with the Chess Merida font.
Incidentally the installation instructions should be super simple when we reach that stage. I have put Rybka into the setup exe now and it is also the default engine. So it should be literally, download - run - play.
The bewildering complexity and number of choices available is things like the Arena download(s) for example were one of the motivating factors in developing my alternative solution in the first place.
Thank you for your support in this thread and thank you for giving me the idea to write the program in the first place (as I explained in the original post of the thread).
[Immediate (short term) Issues]
Uninstall sometimes doesn't remove Program Files\Tarrasch directory (Vista only?)
Excessive CPU idling time currently required to prevent clock display slip
Mix and match testing. Ensure that the Tarrasch Chess GUI supports UCI engines other that Rybka and the Tarrasch Toy Engine. Ensure that the Tarrasch Toy Engine runs in other UCI GUIs. (I've put no effort into mix and match to date which is a real failure on my part - I've received a little feedback to indicate all is not well in this area which is disappointing but hardly surprising unfortunately).
There are many other issues of enhanced functionality that I will then feel in a position to address as time and ongoing interest allow. I will list them briefly here for reference later.
[Medium and long term issues]
Localization, allow some notation options (Sc3 instead of Nc3 etc.), allow Figurine notation
A small selection of engine options to better support human vs engine play
--> calculate during human's time on/off (aka ponder = the permanent brain :-) )
--> (max.) number of CPU cores to use by the engine
--> (max.) hash table size
Optional board graphics and colours
Variation display allowing better .pgn support
Engine vs Engine play including a complete suite of engine options and and a complete suite of tournament and match formats.
Port to Mac, Linux
Port to iPhone (intriguing possibility of making a few $:-)
I will contact you again when I have addressed the immediate/short term issues and then we can maybe get the Tarrasch GUI onto your installation page.
> Uninstall sometimes doesn't remove Program Files\Tarrasch directory (Vista only?)
I don't think that this is a major problem, and I would put it on the low priority list. It is just something experienced users will notice, but it is a minor flaw because the remaining directory (or directories) are empty and cause no harm.
CPU idling needs to be fixed and I consider that a top priority. Nobody wants an interface which causes his cooling system to "go wild" although the interface has no processing to do. A clock normally doesn't cause noticeable CPU load (compare the Windows clock; how much CPU load does it cause although it's always up to date?). That urgently needs to be reduced to less than 0.5% of one core. I'm sure you can do that, somehow. Maybe there are open source interfaces, where you can take a look into their clock programming code.
On the other hand, I consider configurable engine options, continuous text notation and variation display to be important. If you can implement that, your interface would suddenly meet most of the top standards.
A) Configurable engine options is a problem for me because I really need per engine persistence on these. In other words, each engine would need a section of the .ini file where a set of options are stored. If I didn't do this and just saved one value of each of ponder, max cores and max hash and attempt to apply that to any engine, I think it would be a kludge. In other words I feel if I am going to have engine management, I should have a proper engine management scheme that will scale up to all options available for any engine.
B) Continuous text notation and variation display are very important to me, I didn't implement them originally only because I the method I've used to avoid them is basically a shortcut that's allowed me to get something useful out there more quickly.
Having said that if the package as a whole currently has a "difficulty of implementation" of say 100 points, then I think adding A) will take that to maybe 105 and then B) will take it to 120. So I am kind of pleased you think I could meet most of the top standards by putting in only another 20% of the work I've already done. I think I will stick to my current short term plan to get my package to V1.0 status and get it hosted on the Rybka site very soon. I will then try to get to V1.1 (or V2.0?) within another couple of months with A) and B) being part of that version.
Thanks as always for your perceptive thoughts.
> Resizable Graphics
This should get higher priority, on my 800x600 I don't get to see the engine kibitzing, allowing for a smaller board would help:
You have also plenty of space at the right of the board, you could move the engine kitbitzing to there if it's easier than allowing board resizing.
> I assume you have a good reason for 800x600 in 2009 :-)
Of course, I'll move to a 1024x768 resolution if you buy me a new monitor ;9
I run it at 150 hz. If you have some "2009" monitor that can hit that refresh rate at 1024, do tell.
> I run it at 150 hz.
I found that the higher the refresh rate, the less sharp the display becomes. I see no flickering with 75 Hz. Some people may need 80 or 85 Hz, but I doubt that anything higher is recommendable. I suggest to try 80 Hz and see if your display is sharper that with 150 Hz, and if you notice any flickering.
It's another case of "maximum is not optimum." :-)
P.S. Depending on the (CRT) monitor, switching the moire setting, if available, to OFF can improve the display quality, if there isn't really a moire problem anyway. I just recently discovered that with my Iiyama/Diamondtron CRT.
A "2009" monitor will most probably be a LCD which don't flicker; with that you don't need to care for the refresh rate at all.
The problem with LCDs is that if you use a resolution different from the default, then the logical pixels will be different from the physical pixels, which looks sh...
>A "2009" monitor will most probably be a LCD which don't flicker; with that you don't need to care for the refresh rate at all.
The thing is that I like high framerates, and it's almost impossible to get > 85 hz on an LCD, not because the response time doesn't support it, 5 ms response time is already able to change 200 times in 1000 ms, or 200 hz, but the electronics inside the LCD rarely support (if ever) greater than 85 hz. The vid card could be another bottleneck, since it is more difficult and more data for it to process every pixel, hence the need for dvi vs. vga out, and we are coming to the limits of dvi already (See Toshiba's silly 3840 X 2400 LCD that requires 4 dvi cables, not silly because the resolution isn't wicked cool, but silly because it's a classic case of forcing inadequate technology into severe contortions to break a few records and get some PR points).
My CRT doesn't flicker, so that's not the issue. I just like > 85 hz. I have my reasons :-)
In my opinion LCD's are pretty much inferior to CRT's in every category with the exception that they take up so much less space. They are by no means bad though, but don't support my purposes at this time.
I think it's similar to wireless vs. cabled lan, wireless (with current tech) can be wayyyyy more convenient, but otherwise it is inferior in almost every way to using a cable, security (glorified radio station), speed, and reliability to name a few.
I'm hoping that OLED will beat out CRT's completely. IMOD and EFD seem promising as well, but perhaps those are only for mobiles.
PS: In Germany you can find those old CRT monitors on a scrapyard :)
What's a y-ray?
...I need a better font. Why are the default fonts invariably crappy in Linux?
> If I would be you, I would stop eating and save every penny I can until I would be able to buy a decent monitor :-)
Actually, I would just need to stop eating meat, it's very pricey around here and e.g. oranges are cheaper than dirt, I could save considerable amounts of money if I lived off oranges.
But I love meat and the bottom line is, I'm very happy with my CTR monitor and I think it's perfect, I wouldn't change it for a bigger LCD one (I've used them at the cyber-coffee), I only have problems with applications that don't care about me and either I avoid them like the plague or I bug their programmers until they fix them (with Aquarium, big resolution users also were benefited by the fixes.)
One year ago (+1 month 3 days), almost one out of 5 Rybka forum users that cared to vote on polls used 800x600 or less.
What programming language are you using for the GUI?
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill